The `uniprint` device allows the user to provide various string fragments as device options, which are later appended to the output file. Two of these parameters, `upWriteComponentCommands` and `upYMoveCommand`, are actually treated as format strings, specifically for `gp_fprintf` and `gs_snprintf`. For these, the intention is for the user to include just one format specifier in the string, but there is no logic preventing arbitrary format strings (with multiple specifiers) from being used. With full control over the format string (by setting a page device with the respective options), and read access to the device output (by setting it to a temporary file path), an attacker can abuse this to leak data from the stack and perform memory corruption. This is specifically impactful in the cases of `gs_snprintf` (as opposed to `gp_fprintf`), as its format-string parsing logic is not hardened by compiler measures like `D_FORTIFY_SOURCE`, while it still supports the `%n` modifier. References: https://ghostscript.readthedocs.io/en/gs10.03.1/News.html https://bugs.ghostscript.com/show_bug.cgi?id=707662 Upstream commit: https://cgit.ghostscript.com/cgi-bin/cgit.cgi/ghostpdl.git/commit/?id=3b1735085ecef20b29e8db3416ab36de93e86d1f
Created ghostscript tracking bugs for this issue: Affects: fedora-all [bug 2293951]
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:6197 https://access.redhat.com/errata/RHSA-2024:6197
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Extended Update Support Via RHSA-2024:6466 https://access.redhat.com/errata/RHSA-2024:6466