CVE-2026-43426: usb: renesas_usbhs: fix use-after-free in ISR during device removal

Published May 8, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

usb: renesasusbhs: fix use-after-free in ISR during device removal

In usbhsremove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhsinterrupt) is still registered. If an interrupt fires after usbhspiperemove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free.

Fix this by calling devmfreeirq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhspiperemove() is called.

Affected Software

12 affected components
Linux Linux kernel
Linux Linux kernel>=3.0<5.10.253
Linux Linux kernel>=5.11<5.15.203
Linux Linux kernel>=5.16<6.1.167
Linux Linux kernel>=6.2<6.6.130
Linux Linux kernel>=6.7<6.12.78
Linux Linux kernel>=6.13<6.18.19
Linux Linux kernel>=6.19<6.19.9
Linux Linux kernel=7.0-rc1
Linux Linux kernel=7.0-rc2
Linux Linux kernel=7.0-rc3
Linux Linux kernel=7.0-rc4

Event History

May 8, 2026
CVE Published
via MITRE·02:21 PM
Data Sourced
via MITRE·02:21 PM
Description
Data Sourced
via NVD·03:16 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who is exposed to this issue?

Systems using the Linux kernel's Renesas USBHS driver are exposed during removal or unbinding of the affected device driver. Exploitation requires local access and low privileges, according to the CVSS vector.

2

What condition triggers the use-after-free?

The issue occurs if an interrupt is delivered after usbhs_pipe_remove() frees the pipe array and related resources, but before the driver has been fully unbound. The still-registered usbhs_interrupt handler can then dereference freed memory.

3

What is the impact if exploitation succeeds?

The vulnerability is rated high with CVSS 7.8 and has high confidentiality, integrity, and availability impact. It can result in access to or modification of data and disruption of the affected system.

4

What should be done if patching is not immediately possible?

The provided data identifies a patch as available but does not specify a workaround. Prioritize applying the available kernel fix, which frees the IRQ before resource removal so the interrupt handler is disabled and synchronized.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203