| Summary: | [RCE] DOCXWRITE TXTWRITE device: Text buffer overflow with long characters | ||
|---|---|---|---|
| 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 |
||
Created attachment 26192 [details]
exploit
Exploit for x64 Linux
gs -q -sDEVICE=txtwrite -sOutputFile=/dev/null textbuffer.ps
I thought it would be better to pass in a buffer length, but that resulted in more changes than I really wanted to do because it involved adding error handling to places that didn't do it. So in the end I adopted the patch, but I preserved the deleted comment (because it's useful to me) and added another comment explaining the magic number of '4 * sizeof(unsigned short)' One day we may even get round to rewriting the Unicode handling. CVE-2025-27831 |
Created attachment 26191 [details] patch The "docxwrite" and "txtwrite" devices expect a maximum of 4 code units per character when rendering text, and if a font contains a longer value, it results in a buffer overflow. I also fixed the length in memcpy when copying predefined glyph values, which is unrelated to this vulnerability.