CVE-2026-99210 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/rocket: clear rdev on device init failure
rocket_probe() stores the return value from rocket_device_init() in the file-scoped rdev pointer before checking whether it is an error pointer. If rocket_device_init() fails, rdev is left as an ERR_PTR.
The rdev pointer is also used as the marker for whether the shared rocket device has already been initialized. A later core probe can therefore see a non-NULL rdev, skip rocket_device_init(), and dereference the error pointer when reading rdev->num_cores.
Save the error code and clear rdev before returning from the rocket_device_init() failure path.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in the Linux kernel's Rocket serial driver involves a critical logic flaw within the device initialization sequence, specifically located in the probe function responsible for setting up shared hardware resources. The core issue stems from an incorrect handling of error conditions during the initialization phase where the return value of rocket_device_init is stored directly into a file-scoped pointer named rdev without immediate validation against standard kernel error macros. In Linux kernel programming it is common practice to encode negative error codes as special pointers using ERR_PTR when functions cannot return NULL for success and distinct values for failure. However, in this specific implementation the code proceeds to assign the potentially erroneous pointer to rdev before verifying whether the operation actually succeeded or failed. This creates a state where if rocket_device_init encounters an issue such as resource unavailability hardware misconfiguration or driver binding conflicts it returns an error encoded as a high-address pointer which is then mistakenly treated as a valid memory address by subsequent logic blocks that do not perform adequate validation checks before dereferencing the structure members contained within.
This flawed state management has significant operational implications for system stability and security because rdev serves a dual purpose in this driver architecture. It acts both as a handle to the initialized device context and as a flag indicating whether the shared rocket device infrastructure has already been brought online by a previous probe operation. When an initial initialization attempt fails but leaves rdev populated with an error pointer, subsequent probes for other cores or devices associated with the same hardware will observe that rdev is non-NULL. Consequently these later probes will assume successful prior initialization and skip calling rocket_device_init themselves to avoid redundant setup procedures. Instead they proceed directly to access members of the device structure such as num_cores under the false assumption that a valid object exists at that memory location. Dereferencing an ERR_PTR results in accessing invalid kernel memory addresses which typically triggers a page fault leading to an immediate kernel panic or system crash effectively causing a denial of service condition for any user attempting to utilize this hardware interface.
From a vulnerability classification perspective this defect aligns with CWE-252 unchecked return value and CWE-476 NULL pointer dereference although technically it involves error pointers rather than null values which makes detection by static analysis tools more difficult due to the non-standard nature of ERR_PTR usage in failure paths. The attack vector is primarily local requiring physical or logical access to trigger device enumeration sequences that result in initialization failures such as through resource exhaustion attacks or hardware fault injection scenarios. In terms of MITRE ATT&CK mapping this behavior corresponds to T1499 endpoint denial of service where the attacker leverages a software flaw to disrupt system availability rather than gaining unauthorized access or privilege escalation although the resulting instability could potentially be chained with other vulnerabilities for more complex exploitation paths involving kernel memory corruption if the error pointer dereference leads to use-after-free conditions in certain race scenarios.
The remediation strategy implemented by clearing rdev upon failure ensures that subsequent probe operations correctly identify the device as uninitialized and attempt proper initialization rather than skipping critical setup steps based on stale state information. This fix restores the integrity of the driver's internal state machine preventing invalid memory accesses while maintaining correct resource management semantics. Administrators should ensure their systems are updated with kernel patches addressing this specific rocket serial driver flaw particularly in environments where hardware reliability is paramount or where automated device enumeration processes might trigger repeated initialization attempts under varying load conditions that could expose race windows between successful and failed probe sequences. Regular auditing of kernel logs for early-stage driver failures can also help identify instances where such errors occur allowing proactive maintenance before they impact system uptime through unexpected reboots caused by the resulting oops events in production environments relying on Rocket serial communication protocols.