https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 21:35:16 +0000 https://vulnerability.circl.lu/vuln/cve-2026-46167 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl</p> <p>Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred.</p> <p>Ideally that short command should be detected and error out, but many printers are known to send &#34;incorrect&#34; responses back so we can&#39;t just do that.</p> <p>statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl.</p> <p>usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller.</p> <p>Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no &#34;leak&#34; of information happening.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl</p> <p>Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred.</p> <p>Ideally that short command should be detected and error out, but many printers are known to send &#34;incorrect&#34; responses back so we can&#39;t just do that.</p> <p>statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl.</p> <p>usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller.</p> <p>Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no &#34;leak&#34; of information happening.</p> https://vulnerability.circl.lu/vuln/cve-2026-46167