Bug 2482617 (CVE-2026-46167) - CVE-2026-46167 kernel: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl
Summary: CVE-2026-46167 kernel: usb: usblp: fix uninitialized heap leak via LPGETSTATU...
Keywords:
Status: NEW
Alias: CVE-2026-46167
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-28 11:06 UTC by OSIDB Bzimport
Modified: 2026-05-28 15:21 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-05-28 11:06:03 UTC
In the Linux kernel, the following vulnerability has been resolved:

usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl

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.

Ideally that short command should be detected and error out, but many
printers are known to send "incorrect" responses back so we can't just
do that.

statusbuf is kmalloc(8) at probe time and never filled before the first
LPGETSTATUS ioctl.

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.

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
"leak" of information happening.


Note You need to log in before you can comment on or make changes to this bug.