CVE-2026-89983: i2c: core: fix debugfs UAF on adapter removal
In the Linux kernel, the following vulnerability has been resolved:
i2c: core: fix debugfs UAF on adapter removal
i2cdeladapter() frees the adapter's debugfs directory before it unregisters the adapter device, but the newdevice sysfs attribute stays writable until devicedel(). A write racing with removal still reaches i2cdeviceprobe(), which passes the freed adap->debugfs to debugfscreatedir() as the new client's parent:
BUG: KASAN: slab-use-after-free in lookupnopermcommon+0x407/0x430 Read of size 4 at addr ffff88803ef87810 by task syz.0.61/6090 lookupnopermcommon+0x407/0x430 simplestartcreating+0x9c/0x110 debugfsstartcreating+0xdb/0x1a0 debugfscreatedir+0x24/0x350 i2cdeviceprobe+0x814/0xbf0
It's technically possible to create a client after i2cderegisterclients has run. That client will never be unregistered and make waitforcompletion hang.
Close the window by removing the newdevice attribute at the start of i2cdeladapter(). deviceremovefile() will drain any clients left.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
A write to an I2C adapter's writable new_device sysfs attribute must race with removal of that adapter. The write can reach i2c_device_probe() after the adapter's debugfs directory has been freed but before the adapter device is unregistered.
What additional impact can occur besides the use-after-free?
A client can technically be created after i2c_deregister_clients has run. That client will not be unregistered, which can cause wait_for_completion to hang.
What does the fix change?
The fix removes the new_device attribute at the start of i2c_del_adapter(), closing the race window. device_remove_file() also drains clients that remain.