CVE-2026-43426

What it actually does

CVE-2026-43426 is a local use-after-free flaw in the Linux kernel Renesas USBHS driver removal path. During usbhs_remove(), driver resources, including the pipe array, can be freed while the usbhs_interrupt interrupt service routine remains registered. If an interrupt occurs in the small window after usbhs_pipe_remove() has freed memory but before the driver is fully unbound, the ISR may dereference freed kernel memory. Successful exploitation could cause kernel memory corruption, leading to local privilege escalation, kernel crash, or potentially arbitrary kernel-code execution depending on hardware availability, memory layout, and exploit reliability.

Why it matters to the business

Systems using affected Linux kernels with Renesas USBHS hardware or the vulnerable driver enabled may be exposed to local privilege escalation or denial of service. An attacker who already has local access could potentially gain full control of the system or crash it, affecting device reliability and operational continuity. Because this is not currently in CISA KEV, has very low EPSS, and no known public exploit maturity, broad internet-scale exploitation is unlikely; however, embedded, industrial, automotive, appliance, and other hardware platforms using Renesas USBHS should prioritize kernel updates because local kernel privilege escalation can defeat application sandboxing and device hardening.

How an attack unfolds

An attacker first needs local execution privileges on a system where the vulnerable Renesas USBHS driver is present and bound to hardware. The attacker then attempts to influence device removal or driver unbind behavior while causing or racing USBHS interrupts. The vulnerable sequence occurs when usbhs_remove() frees pipe-related resources before the interrupt handler has been freed and synchronized. If an interrupt lands in that race window, usbhs_interrupt can access memory that has already been released. With sufficient control over timing and heap state, the attacker may turn the use-after-free into memory corruption to crash the kernel or, in a more advanced exploit, corrupt kernel structures to elevate privileges. Practical exploitation is likely hardware- and timing-dependent and may be difficult without direct access to the affected device or platform.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Renesas USBHS driver, which calls devm_free_irq() before freeing driver resources so the interrupt handler is disabled and synchronized before usbhs_pipe_remove() runs. If vendor kernels are used, apply the distribution, device-vendor, or board-support-package update that backports this fix. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the renesas_usbhs driver if not required, preventing unprivileged users from loading or unloading kernel modules, restricting local shell access, limiting access to debugfs/sysfs interfaces that can trigger driver unbind or device removal, and enforcing least privilege and application sandboxing. For embedded products, incorporate the patched kernel into firmware images and regression-test USB device attach/remove and suspend/resume behavior.

How to confirm the fix worked

Confirm that the running kernel includes the fix by checking the vendor security advisory, kernel changelog, or source tree for the Renesas USBHS change that frees/synchronizes the IRQ with devm_free_irq() before usbhs_pipe_remove(). Verify the deployed kernel package version or firmware build corresponds to a fixed vendor release. Determine exposure by checking whether CONFIG_USB_RENESAS_USBHS is enabled and whether the renesas_usbhs driver is loaded, built in, or bound to hardware. On running systems, inspect lsmod, /sys/bus/platform/drivers/, /proc/interrupts, dmesg, and kernel configuration files such as /boot/config-$(uname -r). After updating, perform controlled USBHS device attach/remove, driver unbind/rebind, suspend/resume, and reboot tests while monitoring dmesg for use-after-free, KASAN, BUG, Oops, panic, or IRQ-related warnings.

Typical attack path

1. Obtain local code execution on a Linux system with the vulnerable Renesas USBHS driver loaded and relevant hardware present.
2. Identify whether the renesas_usbhs driver is active, built into the kernel, or available as a loadable module.
3. Trigger or influence USBHS device removal, platform-device unbind, module removal, or a related driver teardown path.
4. Generate or race USBHS interrupts during the window after driver resources are freed but before the interrupt handler is disabled and synchronized.
5. Cause the interrupt handler to dereference freed memory, resulting in kernel memory corruption or crash.
6. Use memory corruption primitives, if reliable enough, to escalate privileges to kernel/root level or disrupt system availability.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel and system logs rather than network logs, because this is a local kernel-driver race condition. Relevant sources include dmesg, journald kernel entries, /var/log/kern.log, /var/log/messages, pstore/ramoops, kdump/vmcore, crash dumps, auditd records for module loading or sysfs driver unbind operations, and EDR telemetry showing local commands interacting with /sys/bus/platform/drivers/renesas_usbhs or kernel modules. Indicators include kernel Oops, panic, BUG, KASAN use-after-free, slab corruption, or general-protection-fault messages referencing usbhs_interrupt, usbhs_remove, usbhs_pipe_remove, renesas_usbhs, or IRQ handling. Also review timestamps around USB device removal, driver unbind/rebind, rmmod/modprobe activity, suspend/resume, and unexpected privilege changes. Absence of these artifacts does not prove non-exploitation because a successful kernel memory-corruption exploit may leave limited logs, especially if logging is volatile or the system reboots quickly.

• usbhs_interrupt
• usbhs_remove
• usbhs_pipe_remove
• renesas_usbhs
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• /sys/bus/platform/drivers/renesas_usbhs/unbind
• /sys/bus/platform/drivers/renesas_usbhs/bind
• rmmod renesas_usbhs
• modprobe -r renesas_usbhs
• devm_free_irq
• usb: renesas_usbhs

What your security team should do

• Inventory Linux systems and embedded devices for Renesas USBHS hardware or CONFIG_USB_RENESAS_USBHS support, prioritizing appliances, OT/IoT devices, custom boards, and vendor firmware images.
• Patch affected kernels through the operating-system, device-vendor, or board-support-package update channel; verify that the specific Renesas USBHS IRQ-freeing fix is present.
• Prioritize remediation on systems that allow local user access, run untrusted workloads, expose debug or maintenance shells, or permit driver/module unbind operations.
• If patching is delayed, disable or blacklist the renesas_usbhs driver where operationally safe and restrict kernel module loading/unloading and sysfs driver unbind access to trusted administrators only.
• Enable and review kernel telemetry for crashes and memory-safety findings, including dmesg, journald/kern.log, pstore, kdump, KASAN reports, and watchdog resets.
• Investigate unexplained kernel panics, USBHS driver crashes, or privilege-escalation events on affected hardware, especially around device removal, driver unbind, module unload, suspend/resume, or USB interrupt activity.
• Track distribution and hardware-vendor advisories because fixed version numbers may differ across mainline kernels, long-term-support kernels, and embedded vendor branches.