CVE-2026-46151

What it actually does

This flaw is a Linux kernel heap information disclosure in the USB printer driver, usblp. When querying a printer for its IEEE 1284 device ID, the driver loses the actual byte count returned by the USB control transfer and then trusts the two-byte length field supplied by the device. A malicious or malfunctioning USB printer can return only the length prefix while claiming a much larger device ID, causing the kernel to expose stale, uninitialized heap contents from the 1024-byte allocation. The stale data can be read through the ieee1284_id sysfs attribute, truncated at the first NUL byte, or through the printer device ioctl path, which can return up to roughly 1021 bytes of prior kernel heap data per query. Exploitation requires local interaction with a USB printer-class device and access to the exposed printer interface; this is not a remote network vulnerability.

Why it matters to the business

The practical risk is leakage of sensitive data from kernel memory on systems that allow USB printer devices or USB device emulation. In most server environments the exposure is limited because physical or local device access is required, but the impact can be meaningful for workstations, kiosks, labs, print servers, shared Linux desktops, and environments where USB/IP, virtual USB passthrough, or untrusted peripherals are used. Exploitation could disclose fragments of secrets, credentials, document metadata, kernel pointers, or other process data that happened to be present in recycled heap memory. The CVE is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so remediation should be prioritized based on USB exposure and endpoint sensitivity rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker prepares or controls a USB device that identifies as a USB printer supported by the Linux usblp driver. When the host probes the device or refreshes its IEEE 1284 device ID, the malicious device responds to the GET_DEVICE_ID control request with a short response containing only a two-byte big-endian length, such as a value claiming a long identifier, while omitting the actual identifier body. Because the driver discarded the real transfer length, it assumes the claimed length is valid and leaves the rest of the kernel buffer unchanged. The attacker, or a cooperating local user/process with access to the printer interface, then reads the ieee1284_id sysfs attribute or issues the device-ID ioctl against the USB printer character device. The kernel copies bytes from the partially uninitialized buffer to user space, leaking stale heap contents. The attacker may repeat attach, probe, and read cycles to collect multiple memory fragments, though the content is opportunistic and not attacker-selected with precision.

How to fix it

Apply a kernel update that includes the usblp fix that zeroes the device-ID buffer before each request and correctly prevents stale heap disclosure from short GET_DEVICE_ID responses. Because no exact fixed package versions were provided, use the fixed kernel releases from the Linux distribution or vendor advisory for the affected branch. Prioritize updates on Linux desktops, print servers, kiosks, build/test systems with USB access, virtualization hosts using USB passthrough, and any system where untrusted users can attach USB peripherals. If immediate patching is not possible, reduce exposure by disabling or blacklisting the usblp module where USB printer support is not required, restricting access to /dev/usb/lp* device nodes, disabling USB device passthrough for untrusted guests, enforcing USB device-control policies, and physically limiting access to USB ports. Where printing is required, prefer trusted network printing paths over direct attachment of untrusted USB printer-class devices until patched.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the usblp short-response heap leak; checking only installed packages is insufficient if the system has not rebooted into the fixed kernel. Validate with uname -r, package manager kernel version data, and the applicable distribution security advisory. Confirm whether the usblp module is loaded with lsmod or modprobe status, and inventory systems with USB printer device nodes such as /dev/usb/lp*. If mitigation was chosen, verify the usblp module is blacklisted or unavailable, USB printer devices no longer bind to the usblp driver, and non-administrative users cannot read printer device nodes. For higher-assurance testing in a lab, use a controlled USB printer emulation device that returns a short IEEE 1284 ID response and verify that reads from ieee1284_id or the printer ioctl return zeroed data rather than residual heap bytes.

Typical attack path

1. Obtain local/physical ability to connect a USB device, or equivalent access through USB passthrough, USB/IP, virtualization, or a compromised peripheral path.
2. Present a malicious device that enumerates as a USB printer handled by the Linux usblp driver.
3. Respond to the IEEE 1284 GET_DEVICE_ID control transfer with a short response containing only a crafted two-byte length prefix that claims a much larger ID.
4. Allow the vulnerable driver to cache the claimed device ID while leaving the rest of the kmalloc buffer populated with stale heap data.
5. Read the exposed sysfs ieee1284_id attribute or issue the relevant USB printer ioctl from a local process with access to the device node.
6. Collect leaked bytes and repeat the operation to recover additional kernel heap fragments.

How to detect it

Evidence of successful exploitation is difficult to prove after the fact because the vulnerability leaks memory through normal sysfs reads or printer ioctls and does not necessarily create kernel errors. Focus detection on exposure and suspicious local activity. Review kernel and system logs for new USB printer-class devices, unexpected loading of the usblp driver, or printer attachments at unusual times. Use auditd, eBPF, EDR, or Linux file-access telemetry to identify processes reading ieee1284_id or opening /dev/usb/lp* devices, especially non-printing tools such as shells, scripting runtimes, custom binaries, hexdump utilities, or repeated polling loops. Investigate unknown USB vendor/product IDs that enumerated as printers, short-lived USB printer connections, repeated attach/detach cycles, and USB devices connected to sensitive systems where direct USB printing is not expected. If audit logging was enabled, look for open/read access to sysfs ieee1284_id attributes and ioctl activity on /dev/usb/lp* by users or processes outside normal printing workflows. For forensic review, correlate USB connection times with command history, process execution logs, udev events, and device-node access logs.

• usblp
• usbcore: registered new interface driver usblp
• /dev/usb/lp0
• /dev/usb/lp1
• /dev/usb/lp2
• /sys/class/usb/lp0/device/ieee1284_id
• /sys/class/usb/lp1/device/ieee1284_id
• /sys/class/usb/lp2/device/ieee1284_id
• ieee1284_id
• IOCNR_GET_DEVICE_ID
• GET_DEVICE_ID
• name="/dev/usb/lp
• comm="cat"
• comm="hexdump"
• comm="xxd"
• comm="python"
• comm="perl"
• comm="bash"

What your security team should do

• Patch affected Linux kernels through the operating system vendor and reboot into the fixed kernel, prioritizing systems with direct USB access or USB passthrough.
• Inventory endpoints and servers where the usblp driver is loaded or where /dev/usb/lp* exists, and use that inventory to scope remediation.
• Disable or blacklist usblp on systems that do not require direct USB printer support.
• Restrict local access to USB printer device nodes and audit membership in groups that can access printer devices, commonly lp or similar distribution-specific groups.
• Apply USB device-control policy to block untrusted printer-class USB devices on sensitive workstations, kiosks, shared desktops, and administrative endpoints.
• Review virtualization and remote-USB configurations to ensure untrusted guests or users cannot attach arbitrary USB printer-class devices to vulnerable hosts.
• Monitor for unusual reads of ieee1284_id or ioctl activity against /dev/usb/lp* from unexpected users, services, or scripts.
• Because this issue is not KEV-listed and has low EPSS in the provided data, track it as a targeted local/peripheral risk rather than an internet-exposed mass-exploitation risk.