Package: src:papplVersion: 1.3.1-2.1Severity: graveTags: security upstream fixed-upstreamDear Maintainer,libpappl 1.3.1 as shipped in trixie carries two memory-safety defects thatare fixed in upstream PAPPL but not in the packaged version. Both arereachable by any client that can open a printer application's IPP port, andboth were reproduced to a crash against 1.3.1-2.1+b2 on trixie (amd64) whiledeveloping a printer application against this library.I am reporting them together because they share a cause — anattacker-controlled count used without being bounded — and because the fix inboth cases is an upstream commit that already exists.(1) Out-of-bounds write while dithering an 8-bit raster wider than the page pappl/job-process.c, _papplJobProcessRaster Fixed upstream by commit 4587888f50 Confirmed unpatched in 1.3.1 at job-process.c:696, :718 and :739; pappl/job-filter.c:412 has the same pattern for the image filters.The output line is allocated from the *job's* header: if ((line = malloc(options->header.cupsBytesPerLine)) == NULL)while the dither loop is bounded by the *document's* header: for (x = 0, lineptr = line, ...; x < header.cupsWidth; x ++, pixptr ++)When the incoming raster is wider than the printer's page, lineptr walks pastthe end of line. A driver cannot prevent this: the overflow happens insidelibpappl, before the driver's rwriteline callback is reached.Note that declaring 1-bit output does not avoid the path. ForcingPAPPL_PWG_RASTER_TYPE_BLACK_1 constrains the output, not the input, and isprecisely what selects the dithering path for an 8-bit document.Reproduced: an 8-bit grayscale PWG raster 40000 px wide, submitted withipptool to a printer application whose page is 4960 px at 600 dpi (A4). Theserver dies with SIGABRT and glibc reports "corrupted size vs. prev_size". Araster that fits the page, including one slightly narrower than the page at5000 px, is dithered without incident, which places the trigger at the widthmismatch rather than at the 8-bit path.(2) Stack buffer overflow from an oversized media-ready list pappl/printer-ipp.c, _papplPrinterSetAttributes Fixed upstream by commit 44327aaac3 Confirmed unpatched in 1.3.1 at printer-ipp.c:1045 (media-col-ready) and :1068 (media-ready).A client-supplied list is copied into driver_data.media_ready, which ispappl_media_col_t[PAPPL_MAX_SOURCE] — 16 entries — inside apappl_pr_driver_data_t declared on the stack at printer-ipp.c:911. Thepreflight compares the count against PAPPL_MAX_SOURCE only to decide theresponse's unsupported-attributes status; the copy loop then runs regardless: count = ippGetCount(rattr); for (i = 0; i < count; i ++) _papplMediaColImport(ippGetCollection(rattr, i), driver_data.media_ready + i);Each entry is 228 bytes and the enclosing struct is 8728 bytes, so roughlytwenty entries fit inside the struct before the copy reaches the rest of thestack frame.Reproduced: Set-Printer-Attributes carrying 512 media-ready values kills theserver with SIGSEGV. Counts up to 32 did not crash in testing, which is thepart that worries me most: a count in the low twenties overwrites adjacentstack contents without an immediate crash, so a carefully sized request issilent corruption rather than a clean abort. Set-Printer-Attributes isaccepted with no authentication service configured.ExposureIn my own application the listener is bound to 127.0.0.1, which makes bothfaults local rather than remote. That is a property of my configuration andnot of the library: papplSystemAddListeners takes whatever address theapplication passes, and a printer application that listens on a networkinterface — which is what the framework is for — inherits both asremotely reachable faults. I would not want the loopback case to set theseverity.For (2) I am treating denial of service as the floor rather than the ceiling:a stack overflow with attacker-controlled contents is not something I amwilling to characterise more precisely from a black-box crash.Suggested fixCherry-pick 4587888f50 and 44327aaac3 into the trixie package, or update to anupstream release that contains both. I have not prepared a patch against theDebian packaging; if that would help, say so and I will.ReproducersBoth crashes are reproduced by a self-contained script in my project, whichruns a printer application on the loopback address in a temporary directoryand asserts on the server's exit signal, so the checks fail if a futurelibpappl stops crashing: https://github.com/caganerg/ml216x-printer-app scripts/security-probe.py --case dither (1) scripts/security-probe.py --case ready-media (2)The reasoning behind both, with the line numbers as confirmed in 1.3.1, is indocs/SECURITY-REVIEW.md in the same repository.System information: Debian trixie, amd64; libpappl1t64 1.3.1-2.1+b2;libcups2t64 2.4.10.Thank you for maintaining this package. -- Çağan Ergün