| Summary: | [RCE] Buffer overflow caused by an oversized Type 4 function in a PDF | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | zhutyra |
| Component: | Security (public) | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | carnil, dr, jsmeix, ken.sharp, marc.deslauriers, robin.watts, sam, till.kamppeter, zdohnal |
| Priority: | P2 | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
patch
exploit patch |
||
Created attachment 26364 [details]
exploit
An exploit for x64 Linux (requires 6GB of memory)
gs -q -dNODISPLAY func.ps
Created attachment 26373 [details]
patch
One more check in "pdfi_build_halftone_function".
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. CVE-2025-27834 |
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.