Bug 708253 - [RCE] Buffer overflow caused by an oversized Type 4 function in a PDF
Summary: [RCE] Buffer overflow caused by an oversized Type 4 function in a PDF
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Security (public) (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-01-13 20:59 UTC by zhutyra
Modified: 2025-03-20 11:47 UTC (History)
9 users (show)

See Also:
Customer:
Word Size: ---


Attachments
patch (2.55 KB, patch)
2025-01-13 20:59 UTC, zhutyra
Details | Diff
exploit (3.27 MB, application/postscript)
2025-01-13 21:00 UTC, zhutyra
Details
patch (539 bytes, patch)
2025-01-20 06:18 UTC, zhutyra
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description zhutyra 2025-01-13 20:59:34 UTC
Created attachment 26363 [details]
patch

A large Type 4 function definition can overflow the uint counter, causing the allocated buffer to be smaller than required.
Comment 1 zhutyra 2025-01-13 21:00:52 UTC
Created attachment 26364 [details]
exploit

An exploit for x64 Linux (requires 6GB of memory)

gs -q -dNODISPLAY func.ps
Comment 2 zhutyra 2025-01-20 06:18:19 UTC
Created attachment 26373 [details]
patch

One more check in "pdfi_build_halftone_function".
Comment 3 Ken Sharp 2025-01-20 16:18:28 UTC
OK I've chosen to fix this similarly, but different, by checking *size against max_unit / 2 at the start of the loop in pdfi_parse_type4_func_stream() rather than every time we increment *size.

Yes this limits the size of a type 4 function, but these are supposed to be small, I don't feel the limit is unreasonable.

The checks in pdfi_build_function_4 and pdfi_build_halftone_function() are redundant, but I decided to keep them; more checks are better.
Comment 4 Chris Liddell (chrisl) 2025-03-10 09:56:09 UTC
CVE-2025-27834