CVE-2026-46151

Technical summary

The vulnerability resides in usblp_cache_device_id_string(), which parses a 2-byte big-endian length prefix from IEEE 1284 device ID responses without verifying the actual bytes received. usblp_ctrl_msg() discards the transfer byte count, returning only 0/-errno. When a device sends fewer bytes than declared (e.g., 2 bytes claiming a 1023-byte ID), the kmalloc(1024) buffer retains stale heap data. This uninitialized memory is then exposed via the ieee1284_id sysfs attribute (read as a string) and the IOCNR_GET_DEVICE_ID ioctl (copied in full to userspace). The fix zeros the buffer before each request, eliminating the information leak.

Business impact

Organizations running USB printers on Linux systems face a local information-disclosure risk. While exploitation requires local access and control over printer responses, the leak exposes uninitialized kernel memory that could contain session tokens, cryptographic material, or other sensitive data resident in the heap. In multi-tenant or high-security environments (e.g., lab workstations, secure boot sequences), this represents a confidentiality violation that violates defense-in-depth principles.

Affected systems

The Linux kernel is affected across all versions running the usblp (USB Line Printer) driver. This driver is standard in mainstream distributions and is automatically loaded when USB printers are connected. Any system with USB printer support enabled is potentially vulnerable if an attacker can present a malicious printer or intercept USB communication to inject a crafted response.

Exploitability

Exploitation requires local system access and the ability to control or intercept a USB printer's response to a GET_DEVICE_ID control transfer. The attack surface is low in environments where USB ports are restricted or only trusted peripherals are allowed. However, in open lab environments, conference rooms, or shared workstations, an attacker can plant a malicious USB device or supply a crafted printer. Once triggered, the information leak is deterministic and repeatable, with the attacker able to choose leak size and timing. No elevated privileges or complex exploitation steps are required beyond crafting the USB response.

Remediation

Patch the Linux kernel to apply the fix: zero the device ID buffer before sending each control request to the printer. This prevents stale heap data from being readable in the response. Verify that your kernel version includes the upstream fix. For vendors not yet patched, consider disabling USB printer support on systems that do not require it, or restricting USB device attachment via physical port locks or udev policies.

Patch guidance

Apply the upstream Linux kernel fix to the usblp driver. Verify the fix is included in your kernel's stable branch. Consult your distribution's security advisory for the patched kernel version (e.g., Ubuntu, Red Hat, Debian, SUSE). Test printer functionality after patching to ensure no regression. No manual configuration changes are required; the fix is purely in the driver code.

Detection guidance

Monitor for repeated IOCNR_GET_DEVICE_ID ioctl calls or sysfs reads of ieee1284_id on systems with USB printers. Audit dmesg or kernel logs for usb_control_msg errors or short transfers from printers, which may indicate probing for the vulnerability. If feasible, use USB packet sniffing (Wireshark, usbmon) to detect GET_DEVICE_ID responses with short payloads claiming large IDs. Restrict physical USB port access and enforce device whitelisting policies.

Why prioritize this

This is a local information disclosure with medium CVSS (5.5). It is not a remote vulnerability and does not grant code execution. However, kernel memory leaks are serious in defense-in-depth strategies and may expose secrets. Prioritize patching based on environment: high in multi-user or lab settings, lower in locked-down single-user systems. Given the deterministic nature of the leak and its presence in widespread USB printer support, patching should occur as part of routine kernel hardening.

Risk score, explained

CVSS 5.5 (MEDIUM) reflects local-only access, no special privileges needed, and high impact on confidentiality (uninitialized heap exposure). Attack complexity is low because a crafted USB response is straightforward to produce. The scope is unchanged (only the affected user's kernel memory), and there is no integrity or availability impact unless the leaked data is weaponized in a follow-on attack.

Frequently asked questions