Created attachment 26345 [details] patch The function `gp_mswin.c:gp_open_scratch_file_impl` improperly or not at all checks the return values of called functions. In particular, gp_utf8_to_uint16 can fail, leaving the output buffer with only a partially decoded path. This could allow access to arbitrary files. I have fixed or added proper checks and removed one unnecessary dynamic allocation. Also, the function GetTempFileNameWRT should return 0 on failure instead of a value that cannot be recognized as an error.
Created attachment 26346 [details] exploit Debugging note: I use one path just to ensure a valid string is in the stack buffer, and on the next call I take advantage of the truncation, relying on the fact that the buffer already contains a null terminator from the previous call. In a debug build, it's quite unlikely that the buffer's content will persist, and even in a release build, it might occasionally fail. However, overall, it works nicely with your release "10.04.0 for Windows (64 bit) - AGPL". This should create two files "<random>.tmp" and "foo.bar" in the user's Startup folder. gswin64c.exe utftemp.ps
OK I've chosen to change the names of the functions, because I found myself getting confused between 'utf8_to_uint16' and 'gp_utf8_to_uint16' when reviewing the code, and also because the name didn't, to my mind, indicate what was different to the basic gp_ functions. I also reviewed all uses of gp_utf8_to_uint16() and gp_uint16_to_utf8(), which uncovered a number of other places which were not properly checking the error codes, or the returned lengths. Mostly these are in the Windows-specific platform code, or the mswinpr2 printer which is also windows-specific, but there was one case in the ICC parameter parsing. I doubt these are as exploitable, but we should fix them as well, so I've done that as part of the same commit (some of the other places were in the same source file, gp_mswin.c)
CVE-2025-27837
Fixed: https://cgit.ghostscript.com/cgi-bin/cgit.cgi/ghostpdl.git/commit/?id=2cc7667188d