CVE-2026-23030

What it actually does

Double free of a device tree node pointer in rockchip_usb2phy_probe() when devm_request_threaded_irq() fails after the for_each_available_child_of_node() loop has already released the node via of_node_put().

Why it matters to the business

Kernel memory corruption on affected Rockchip-based Linux systems can lead to crashes, denial of service, or potential local privilege escalation during USB PHY initialization; low exploitability keeps immediate operational risk modest but still requires prompt patching on embedded and edge devices.

How an attack unfolds

An attacker with local access or the ability to trigger USB PHY probe failure (for example via module reload or hardware configuration) causes the kernel to execute the error path that calls of_node_put() a second time on an already-freed node, resulting in use-after-free memory corruption.

How to fix it

Update the Linux kernel to the fixed commit b97b2c9808c9a97e0ce30216fa12096d8b0eaa75 or later; for dotnet-bootstrap-9 (MinimOS) upgrade to 9.0.112-r0 or newer. Rebuild and deploy the patched kernel image on all affected Rockchip platforms.

How to confirm the fix worked

Confirm the running kernel contains commit b97b2c9808c9a97e0ce30216fa12096d8b0eaa75, verify probe error paths no longer double-release nodes via code review or targeted fault injection, and ensure USB2 PHY initialization succeeds without crashes under normal and failure conditions.

Typical attack path

1. Gain local execution or module-loading privileges on a Rockchip platform using the inno-usb2 PHY driver
2. Trigger rockchip_usb2phy_probe() such that the child node loop succeeds but devm_request_threaded_irq() subsequently fails
3. Force execution of the put_child error label to perform the second of_node_put()
4. Exploit the resulting double-free for memory corruption or crash

How to detect it

Review kernel logs for double-free warnings, slab corruption messages, or oops traces referencing rockchip_usb2phy_probe and of_node_put during USB PHY initialization; correlate with module load or hardware attach events on Rockchip platforms.

What your security team should do

• Apply the kernel patch or updated package immediately on all Rockchip-based devices
• Prioritize patching of internet-facing or multi-tenant edge systems first
• Monitor for any local kernel oops or USB initialization failures that could indicate attempted exploitation
• Review downstream device images and rebuild pipelines to incorporate the fix