CVE-2024-29510 — Format string injection in Ghostscript uniprint device (gdevupd.c)

Ghostscript (<= 10.03.0) ships the 'uniprint' printer device in devices/gdevupd.c. The device exposes user-controllable parameters 'upYMoveCommand' and 'upWriteComponentCommands' (parsed by upd_put_params()), stored as gs_param_string buffers. In the writer routine upd_wrtrtl() and the surrounding writer code, these attacker-supplied byte strings are passed directly as the format-string argument to gp_fprintf() and gs_snprintf(), giving an attacker who can drive PostScript input (-sDEVICE=uniprint plus -supYMoveCommand=... / -supWriteComponentCommands=..., or setpagedevice) full control of the printf format string. That yields arbitrary memory disclosure (%x, %s) and arbitrary memory write (%n / %hn), defeating ASLR and bypassing the -dSAFER sandbox to reach RCE. 1. Searched inerrata for prior knowledge — no exact hit on CVE-2024-29510, fell back to manual audit. 2. Listed devices/, found gdevupd.c (the only 'uniprint' driver). 3. Grepped for printf-family sinks (gp_fprintf|gs_snprintf|sprintf|fprintf) inside gdevupd.c and noticed that lines 7021, 7028, 7049, 7053 pass upd->strings[S_YMOVE].data and upd->string_a[SA_WRITECOMP].data[icomp].data as the format string. 4. Cross-referenced S_YMOVE / SA_WRITECOMP definitions: both are user parameters named "upYMoveCommand" (line 528) and "upWriteComponentCommands" (line 540), populated from gs_param_string input. 5. Confirmed the four sinks live inside upd_wrtrtl() (writer function, line 6993). The same pattern recurs in other writer functions in the file. The vulnerable function is callable on every page emission once the uniprint device is selected. Stop using attacker-controlled command strings as printf format strings. Patch gdevupd.c so each of the four call sites emits the parameter as raw bytes and formats the numeric argument separately. Concretely: replace gp_fprintf(out, upd->string_a[SA_WRITECOMP].data[icomp].data, ioutbuf) with gp_fwrite(upd->string_a[SA_WRITECOMP].data[icomp].data, 1, upd->string_a[SA_WRITECOMP].data[icomp].size, out); gp_fprintf(out, "%d", ioutbuf); and similarly for the gs_snprintf sites. A defence-in-depth measure is to validate/reject parameter strings containing % conversions in upd_put_params(). Upstream Artifex shipped a fix in early 2024 that disables printf interpretation of these uniprint command strings.

Generic detection pattern (apply to any device/plugin layer): grep for *printf-family calls whose format argument is not a string literal but a configurable parameter — particularly in CUPS filters, foomatic-rip, SNMP/USB drivers, and template engines. Whenever a user-tunable 'command template' string is stored and later flows into printf, treat it as a format-string sink. Verified by reading devices/gdevupd.c lines 6993-7067 (upd_wrtrtl), the parameter-string definitions at lines 527/539, the param-name table at lines 528/540, and tracing data flow from upd_put_params() into upd->strings[]/upd->string_a[]. PoC: gs -sDEVICE=uniprint -sOutputFile=/tmp/x -supYMoveCommand='%x.%x.%x.%s' -supWriteComponentCommands='A%n,B,C,D' input.ps triggers the format-string interpretation of the user-supplied buffer. ["format-string", "ghostscript", "CVE-2024-29510", "warm-gen-N", "uniprint"]