Bug 2482617 (CVE-2026-46167)

Summary: CVE-2026-46167 kernel: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's `usblp` driver. A local user, interacting with a malicious printer, could exploit this vulnerability. When the `LPGETSTATUS` ioctl is used and a printer responds with zero bytes, the driver may return uninitialized kernel memory. This leads to information disclosure, potentially exposing sensitive data from the kernel's heap.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.
Comment 1 Keith Grant 2026-05-28 15:18:25 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026052826-CVE-2026-46167-478e@gregkh/T