CVE-2026-90288 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure
for_each_child_of_node_scoped() releases the node reference on scope exit, so the explicit of_node_put(np) in the devm_phy_create() error path drops it twice.
Drop the redundant of_node_put() and let the scoped cleanup handle it.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel phy subsystem for Renesas R-Car Gen2 platforms contained a resource management flaw related to device tree node reference counting during initialization failures. The vulnerability stems from an incorrect handling of object lifecycles when creating PHY devices, specifically involving the interaction between scoped cleanup macros and explicit release functions. In modern Linux kernel development, the use of scoped helpers such as for_each_child_of_node_scoped is standard practice to ensure automatic resource deallocation upon scope exit, thereby reducing boilerplate code and preventing common memory management errors. However, in this specific implementation within the rcar-gen2 PHY driver, developers retained an explicit call to of_node_put on the device node pointer even when using a scoped iteration macro that already guarantees release at the end of its block or during early return paths.
This redundancy results in a double free scenario for the device tree node reference count. When phy creation fails and the error path is triggered, the code attempts to decrement the reference counter twice: once implicitly by the scoped cleanup mechanism associated with the loop variable, and again explicitly via the manual of_node_put invocation. While immediate kernel panics may not always occur due to how refcounting logic handles underflows or redundant decrements in certain contexts, this behavior violates strict resource management principles and can lead to use-after-free conditions if the reference count reaches zero prematurely while other subsystems still hold references to the node. Such errors compromise system stability and introduce potential security vectors where an attacker might exploit race conditions or memory corruption stemming from invalid pointer dereferences after premature deallocation.
From a vulnerability classification perspective, this issue aligns with CWE-415 Double Free, which describes situations where a program frees a block of memory twice, potentially leading to heap corruption or arbitrary code execution depending on the allocator state and timing. Additionally, it relates to CWE-772 Missing Release of Resource after Effective Lifetime, as the improper handling indicates a lack of adherence to proper resource lifecycle management protocols within the driver initialization sequence. In terms of ATT&CK mapping, while this is primarily an internal kernel stability issue rather than an external attack vector, it falls under T1496 Resource Hijacking if exploited for denial-of-service through system crashes, or more broadly under techniques involving exploitation of software flaws to gain foothold via instability-induced privilege escalation opportunities in complex systems.
The operational impact of this vulnerability includes potential system instability during device enumeration phases, particularly on embedded platforms relying heavily on dynamic PHY configuration at boot time. If the error path is frequently triggered due to hardware misconfiguration or missing firmware resources, repeated double frees could corrupt kernel memory structures over time, leading to unpredictable behavior including crashes, data corruption in adjacent allocations, or security bypasses if heap metadata is compromised. Mitigation involves removing the redundant explicit of_node_put call from the devm_phy_create error handling path and relying entirely on the scoped cleanup mechanism provided by for_each_child_of_node_scoped. This ensures that reference counting remains consistent with kernel best practices, eliminating the risk associated with manual intervention in automatically managed scopes. Developers should audit similar patterns across other PHY drivers to prevent analogous issues elsewhere in the subsystem.