CVE-2026-93283 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
i3c: master: Fix device_register() error path
When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device.
Two problems follow from that:
i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device().
After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel vulnerability in the Inter-Integrated Circuit (I2C) Controller driver involves a critical error handling flaw within the device registration process for I3C master devices. Specifically, the function i3c_master_register_new_i3c_devs() utilizes the standard kernel API device_register() to initialize new I3C device structures. When this initialization fails due to resource constraints or configuration errors, the code attempts to clean up by calling put_device(). This call is intended to release the reference count acquired during registration. However, because no other references exist at that point in the execution flow, putting the device triggers its immediate deallocation via the associated release callback, i3c_device_release(), rather than merely decrementing a counter for later cleanup.
This premature deallocation leads to two distinct technical failures rooted in improper state management during error paths. First, the release function contains an assertion that warns if the descriptor field remains populated. Because the code fails to nullify this pointer before invoking put_device(), the warning is triggered as desc->dev->desc still references the object being freed. Second and more critically, after put_device() frees the memory associated with i3c_device, the parent structure's member desc->dev continues to hold a stale pointer to that now-deallocated memory region. This creates a dangling pointer scenario where subsequent operations may attempt to access invalid memory addresses.
The operational impact of this flaw is significant for system stability and security integrity. If other parts of the I3C subsystem, such as i3c_master_unregister_i3c_devs(), check whether desc->dev is non-NULL before proceeding with device management tasks, they will proceed under the false assumption that a valid object exists. Dereferencing this stale pointer results in undefined behavior, which typically manifests as kernel panics or system crashes due to access violations. In more sophisticated attack scenarios involving local privilege escalation, such memory corruption vulnerabilities can potentially be exploited to execute arbitrary code if an attacker can influence the allocation patterns and timing of these device registrations, although the primary immediate risk is denial of service through system instability.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free, as it involves accessing memory after it has been freed due to incorrect pointer management during error handling. It also relates to CWE-755 Improper Handling of Exceptional Conditions, specifically the failure to properly clean up resources when an operation fails. In terms of ATT&CK mapping, this represents a technical weakness that could be leveraged in techniques associated with Defense Evasion or Impact categories if exploited for system disruption.
To mitigate this vulnerability, developers must ensure that all pointers referencing dynamically allocated objects are explicitly cleared before those objects are deallocated. Specifically, within the error path of i3c_master_register_new_i3c_devs(), desc->dev and any related descriptor fields should be set to NULL prior to calling put_device(). This ensures that subsequent checks for nullity correctly identify the absence of a valid device object, preventing accidental dereferences of freed memory. Maintaining strict invariants during error handling paths is essential for preserving kernel stability and preventing use-after-free conditions in complex driver architectures like I3C subsystems.