CVE-2026-80952: i3c: master: Fix info leak and UAF in device unregister path
In the Linux kernel, the following vulnerability has been resolved:
i3c: master: Fix info leak and UAF in device unregister path
i3cmasterunregisteri3cdevs() clears i3cdev->dev->desc before calling deviceunregister(). During deviceunregister(), devicedel() emits a KOBJREMOVE uevent and unbinds the driver while the device descriptor is still expected to be valid. As a result, i3cdeviceuevent() and a racing modaliasshow() can observe a NULL desc and fall back to an uninitialized stack struct i3cdeviceinfo, leaking kernel stack contents in the generated modalias. Driver .remove() callbacks may also encounter an unexpected NULL desc during unbind.
Keep desc valid until deviceunregister() has completed. Since deviceunregister() drops the device reference and may free the device, take an extra reference with getdevice() before unregistering. Clear desc afterwards and release the extra reference with putdevice(). 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.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for the information leak to occur?
The affected unregister path must run while a KOBJ_REMOVE uevent or a racing read of modalias_show() observes the device after its descriptor has been cleared. In that state, the modalias generation can use an uninitialized stack i3c_device_info structure and expose kernel stack contents.
Can driver removal callbacks be affected?
Yes. During device_unregister(), driver unbind and .remove() callbacks can run while the device descriptor is unexpectedly NULL, which may cause affected callbacks to access invalid state.
What is the relevant mitigation if the fix cannot be applied immediately?
The provided data does not identify a configuration workaround. The issue is specifically tied to unregistering I3C devices, so limiting or avoiding affected I3C device unregister operations reduces exposure until the referenced fix is applied.
How does the fix avoid the use-after-free risk?
It keeps the descriptor valid until device_unregister() completes and takes an additional device reference before unregistering. The descriptor is then cleared only after unregistering, and the extra reference is released afterward, preventing a write to a device that may already have been freed.