CVE-2026-46091

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel igorplugusb media/remote-control USB driver. The flaw involves improper DMA-coherency handling for a USB control request structure, which can be accessed by some USB host controllers during DMA. If the vulnerable code path is triggered, the kernel may experience memory-coherency-related corruption or instability, resulting in an Oops, hang, or panic. Based on the provided scoring, the expected impact is availability loss only, with no indicated confidentiality or integrity impact.

Why it matters to the business

Systems that load or use the vulnerable Linux kernel igorplugusb USB remote-control driver can be crashed by a local low-privileged attacker or by interaction with a triggering USB device. The primary business risk is service interruption: workloads on affected hosts may be disrupted, physical or virtual systems may require reboot, and operational availability may be reduced. The risk is lower than internet-facing remote code execution because exploitation requires local access or relevant USB/device interaction, EPSS is very low, there is no known KEV listing, and no public exploit maturity is reported; however, kernel crashes can still cause meaningful outages on systems where this driver is present.

How an attack unfolds

An attacker first needs local access to an affected Linux system or the ability to cause the system to interact with a relevant igorplugusb-compatible USB device. The attacker then triggers the vulnerable control-request path in the igorplugusb driver. Because the USB request structure does not correctly satisfy DMA-coherency requirements on some host controllers, DMA activity can operate on memory in an unsafe way. The resulting inconsistency can destabilize kernel execution and lead to a crash or hang. There is no evidence in the provided data of active exploitation, ransomware use, or reliable public exploit code.

How to fix it

Upgrade to a Linux kernel build that includes the upstream igorplugusb DMA-coherency fix for the media rc driver. Because no exact fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution or vendor advisory. Where immediate patching is not possible, reduce exposure by blacklisting or unloading the igorplugusb driver if it is not required, restricting physical and logical access to USB devices, disabling unneeded USB peripheral access on sensitive systems, and limiting local shell access to trusted users. Example mitigations include removing the module if loaded and not needed, preventing it from autoloading, and enforcing device-control policies for USB hardware.

How to confirm the fix worked

Confirm that systems are running a vendor kernel version containing the igorplugusb DMA-coherency fix. Check whether the igorplugusb module is present or loaded, for example by reviewing loaded kernel modules and kernel driver paths. Validate mitigation by confirming the module is not loaded and cannot be automatically loaded where the hardware is not required. For patched systems, review vendor changelogs or kernel source/package metadata for the igorplugusb coherency fix, then reboot into the patched kernel and confirm the active kernel version matches the remediated package. Also review recent kernel logs for igorplugusb-related Oops, panic, DMA, or USB control-transfer errors that may indicate previous instability.

Typical attack path

1. Identify a Linux host running an affected kernel with the igorplugusb driver available or loaded.
2. Obtain local low-privileged access to the host, or gain the ability to attach or interact with a relevant USB remote-control device.
3. Trigger the igorplugusb USB control-request handling path repeatedly or under conditions that exercise the DMA-coherency flaw.
4. Cause kernel instability, such as an Oops, panic, hang, or forced reboot.
5. Use the resulting outage to disrupt services or operations running on the affected host.

How to detect it

To determine whether this may have already been exploited, review kernel and system logs for crashes or instability involving the igorplugusb driver, USB control transfers, DMA/coherency errors, kernel Oops events, hangs, or panics. Useful log sources include journald, syslog, kern.log, dmesg output, crash dump records, kdump/vmcore metadata, audit logs for local user activity around the time of a crash, and hardware/USB device attach events. Correlate igorplugusb-related driver messages with sudden reboots, watchdog resets, panic records, or unexpected service interruptions. Because this vulnerability is expected to manifest primarily as denial of service rather than persistent compromise, there may be no durable file, process, registry, or network artifact after reboot. Absence of logs does not rule out exploitation if volatile kernel logs were lost during a panic or hard reset.

• igorplugusb
• /sys/bus/usb/drivers/igorplugusb
• /lib/modules/*/kernel/drivers/media/rc/igorplugusb.ko
• drivers/media/rc/igorplugusb.c
• media: rc: igorplugusb
• kernel: igorplugusb
• Oops:
• Kernel panic
• BUG: unable to handle kernel
• BUG: kernel NULL pointer dereference
• usb control request
• DMA coherency

What your security team should do

• Prioritize patching Linux systems where the igorplugusb driver is loaded, USB peripherals are permitted, or physical/local user access is less tightly controlled.
• Inventory systems for the presence of the igorplugusb module and affected kernel versions.
• If the driver is unnecessary, blacklist or remove it and verify it cannot autoload.
• Apply vendor kernel updates and reboot systems into the fixed kernel; merely installing the package is insufficient if the old kernel remains active.
• Restrict USB device access on servers, kiosks, workstations in shared spaces, and other systems where local or physical access is plausible.
• Monitor kernel logs for igorplugusb-related crashes, Oops messages, panics, and USB/DMA errors.
• Treat unexplained kernel crashes on systems using this driver as potentially security-relevant, even though no known exploitation or KEV activity is currently reported.