CVE-2026-80952 in Linux
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
i3c: master: Fix info leak and UAF in device unregister path
i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before calling device_unregister(). During device_unregister(), device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3c_device_uevent() and a racing modalias_show() can observe a NULL desc and fall back to an uninitialized stack struct i3c_device_info, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind.
Keep desc valid until device_unregister() has completed. Since device_unregister() drops the device reference and may free the device, take an extra reference with get_device() before unregistering. Clear desc afterwards and release the extra reference with put_device(). This preserves the release-time invariant that desc must be NULL while avoiding both the information leak and a potential use-after-free from writing desc after the device has been released.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The Linux kernel's Inter-Integrated Circuit (I2C) Controller driver contains a critical synchronization flaw within its device unregistration sequence, specifically in the i3c_master_unregister_i3c_devs function. This vulnerability arises from an incorrect ordering of operations during the cleanup phase where the device descriptor is cleared prematurely before the underlying device structure has been fully released by the kernel core subsystem. The root cause lies in the interaction between driver-specific teardown logic and the generic Linux device model's lifecycle management, which expects certain fields to remain valid until specific asynchronous events have completed processing.
The technical flaw manifests when i3c_master_unregister_i3c_devs sets the i3cdev->dev->desc pointer to NULL prior to invoking device_unregister(). This action violates a critical invariant maintained by the kernel's kobject subsystem, which assumes that device descriptors remain accessible during the emission of uevents and driver unbinding processes. Specifically, when device_del() is executed as part of the unregister sequence, it triggers a KOBJ_REMOVE uevent notification. Concurrently, if any user-space process or internal kernel thread attempts to read the modalias attribute via sysfs, the function modalias_show() may be invoked. Because the descriptor has already been nullified by the driver's cleanup routine but not yet freed by the core device model, these functions encounter a NULL pointer and fall back to reading an uninitialized stack-allocated struct i3c_device_info structure.
This race condition results in two distinct security implications: information leakage and potential use-after-free conditions. The primary impact is the exposure of sensitive kernel memory contents to user space through the modalias attribute. Since the fallback mechanism reads from a stack buffer that was not properly initialized, it leaks whatever data previously resided on the kernel stack at that location. This constitutes an out-of-bounds read vulnerability classified under CWE-200: Information Exposure and CWE-125: Out-of-bounds Read. Furthermore, driver remove callbacks may encounter unexpected NULL pointers during unbind operations if they assume the descriptor is valid throughout the entire teardown process, potentially leading to crashes or undefined behavior that could be exploited for denial of service attacks.
The operational impact extends beyond simple data leakage. The premature clearing of the device descriptor disrupts the expected state machine of the I3C subsystem, causing instability in systems relying on hot-plug events and dynamic driver binding. Attackers with local access to the system can exploit this race condition by rapidly triggering unregistration while simultaneously polling sysfs attributes or monitoring uevents. This increases the attack surface for privilege escalation if combined with other vulnerabilities that allow exploitation of leaked kernel pointers, such as bypassing Kernel Address Space Layout Randomization (KASLR). The vulnerability aligns with ATT&CK techniques related to System Information Discovery and potentially Defense Evasion through memory corruption artifacts depending on exploit complexity.
To mitigate this vulnerability, the fix involves restructuring the device unregistration sequence to preserve the validity of the device descriptor until all asynchronous operations have completed. This is achieved by taking an additional reference count on the device using get_device() before calling device_unregister(). This ensures that the device structure remains allocated and valid throughout the duration of the unregister process, including during uevent emission and driver unbinding phases. Once device_unregister() completes and drops its internal references, the code then safely clears the desc pointer to maintain the release-time invariant that it must be NULL when finally freed. Finally, the extra reference acquired earlier is released using put_device(), ensuring proper memory management without exposing uninitialized stack data or creating use-after-free conditions from late writes to a potentially freed structure.
System administrators and developers should ensure their kernels are updated with patches addressing this specific I3C master driver issue. For environments where immediate patching is not feasible, restricting access to sysfs attributes related to device modalias can reduce the risk of information leakage. Additionally, enabling strict kernel hardening features such as stack protector randomization helps mitigate the impact of any potential exploitation attempts by making leaked data less predictable and harder to utilize in subsequent attack chains. Continuous monitoring for unusual patterns in uevent emissions or unexpected driver unbind failures may also aid in detecting attempted exploitation of this race condition in real-time environments.