CVE-2026-46167

What it actually does

CVE-2026-46167 is a Linux kernel usblp USB printer driver flaw in the LPGETSTATUS ioctl path. The driver allocates an 8-byte status buffer at device probe time but did not initialize it before the first status request. If a USB printer or USB device presenting as a printer returns zero bytes to the status request, the kernel can read one stale byte from kmalloc heap memory, sign-extend it into an integer, and copy that value to a local userspace caller. The practical impact is a small local kernel heap information disclosure through interaction with a malicious or abnormal USB printer device. The provided CVSS vector indicates local access and low privileges are required, although the vector also lists high availability impact; based on the description, the resolved bug is primarily an information disclosure from uninitialized kernel memory.

Why it matters to the business

Organizations using Linux systems with USB printer support could face limited exposure of kernel memory contents to a local user who can interact with a crafted or malicious USB printer device. The most likely business risk is endpoint compromise support: leaked kernel memory can sometimes help attackers bypass exploit mitigations or improve reliability of a separate local exploit. Because exploitation requires local access and a cooperating malicious USB printer-class device, and because EPSS is very low with no known KEV listing or public exploit maturity, broad internet-scale business risk is low; however, shared workstations, kiosks, lab systems, print stations, and environments allowing untrusted USB devices should treat the issue with higher priority.

How an attack unfolds

An attacker needs local access to a Linux system and the ability to use or attach a USB device that is handled by the usblp driver. The attacker presents a malicious USB printer or printer-emulating device that responds incorrectly to the LPGETSTATUS control request by returning zero bytes. A local process then issues the LPGETSTATUS ioctl against the printer device node, commonly exposed through a device such as /dev/usb/lp0. Because the driver's status buffer was not initialized at probe time, the first zero-length response causes the ioctl path to read stale heap data from the kernel allocation, convert it into a status integer, and return it to userspace. The attacker can repeat collection attempts across device resets or carefully timed allocations to gather small amounts of kernel memory state, potentially using the leak as an auxiliary primitive for another local kernel exploitation chain.

How to fix it

Apply a Linux kernel update that includes the usblp fix which initializes the status buffer at probe time. Because no exact fixed versions were provided, use the security advisory or package metadata from the operating system or kernel vendor to identify the first patched kernel for the distribution in use. Where immediate patching is not possible, reduce exposure by blocking untrusted USB devices, disabling or unloading the usblp module where USB printer support is not required, restricting access to USB printer device nodes, and using device-control policies to prevent arbitrary printer-class USB devices from being attached. Potential mitigations include removing the module with modprobe -r usblp, preventing automatic loading via a modprobe blacklist, and enforcing udev permissions so only trusted users or service accounts can access /dev/usb/lp* devices.

How to confirm the fix worked

Confirm systems are running a vendor kernel package that includes the usblp LPGETSTATUS initialization fix. Validate whether the usblp module is present or loaded with commands such as lsmod | grep '^usblp' and modinfo usblp, then compare the running kernel version from uname -r against the vendor's fixed kernel release. Confirm mitigation by verifying the usblp module cannot be loaded if USB printing is not required, and that printer device nodes such as /dev/usb/lp0 are absent or restricted to authorized users. For patch validation in a test environment, attach a printer-emulating USB device that returns zero bytes for the status request and confirm LPGETSTATUS returns a deterministic initialized value rather than stale heap-derived data.

Typical attack path

1. Gain local code execution or an interactive account on a Linux system with the usblp driver available.
2. Attach or control a malicious USB printer-class device, or emulate one using USB gadget hardware/software.
3. Ensure the device is bound to the Linux usblp driver and exposes a printer device node such as /dev/usb/lp0.
4. Have the malicious device return zero bytes to the driver's status request.
5. Invoke the LPGETSTATUS ioctl from a local process against the USB printer device node.
6. Collect the returned integer value that may contain sign-extended stale kernel heap data.
7. Use the leaked byte-level information to aid additional local exploitation or kernel memory analysis.

How to detect it

Post-exploitation detection is difficult because the vulnerable operation is a local ioctl and may not produce default logs. Focus on indirect evidence: kernel logs for unexpected USB printer attachments, usblp driver binding, repeated disconnect/reconnect events, and creation of /dev/usb/lp* devices; audit logs for access to USB printer character devices; and process telemetry showing unusual custom binaries opening /dev/usb/lp* and issuing ioctls. Review /var/log/kern.log, /var/log/messages, journald kernel logs, auditd records, EDR process/file-device telemetry, and USB device inventory logs. Look for unrecognized printer-class USB devices, abnormal vendor/product IDs, devices repeatedly returning malformed responses, and local processes not associated with normal printing workflows accessing USB printer nodes. If auditd is deployed, consider adding watches on /dev/usb/lp* for read/write/open activity and correlating access with USB attach events. Because the leak is only a one-byte stale heap disclosure path and no public exploit indicators are known, absence of these indicators does not prove non-exploitation.

• usblp
• /dev/usb/lp0
• /dev/usb/lp1
• /dev/usb/lp2
• /dev/usb/lp3
• usb printer
• usblp0
• LPGETSTATUS
• ioctl LPGETSTATUS
• modprobe usblp
• /etc/modprobe.d/blacklist-usblp.conf

What your security team should do

• Patch affected Linux kernels through the operating system vendor's security update channel, prioritizing endpoints and shared systems where untrusted USB devices may be connected.
• Inventory Linux systems with the usblp module loaded or available and identify systems exposing /dev/usb/lp* device nodes.
• Disable or blacklist the usblp module on servers, kiosks, cloud images, containers hosts, and workstations that do not require direct USB printer support.
• Restrict physical USB access and enforce USB device-control policies, especially for printer-class devices in high-trust or shared environments.
• Review local user permissions for USB printer device nodes and remove unnecessary access to lp, printer, or similar device groups where applicable.
• Monitor for unexpected loading of the usblp module, creation of /dev/usb/lp* devices, or unknown USB printer-class devices being attached.
• Treat any evidence of suspicious local ioctl tooling against USB printer devices as a potential precursor to local privilege escalation research or exploit chaining, even though this flaw alone is limited.