CVE-2026-97479: driver core: Avoid warning when removing a device while its supplier is unbinding
In the Linux kernel, the following vulnerability has been resolved:
driver core: Avoid warning when removing a device while its supplier is unbinding
During driver removal, the following warning can appear: WARNING: CPU: 1 PID: 139 at drivers/base/core.c:1497 devicelinksnodriver+0xcc/0xfc ... Call trace: devicelinksnodriver+0xcc/0xfc (P) devicelinksdrivercleanup+0xa8/0xf0 devicereleasedriverinternal+0x208/0x23c devicelinksunbindconsumers+0xe0/0x108 devicereleasedriverinternal+0xec/0x23c devicelinksunbindconsumers+0xe0/0x108 devicereleasedriverinternal+0xec/0x23c devicelinksunbindconsumers+0xe0/0x108 devicereleasedriverinternal+0xec/0x23c driverdetach+0xa0/0x12c busremovedriver+0x6c/0xbc driverunregister+0x30/0x60 pciunregisterdriver+0x20/0x9c lan966xpcidriverexit+0x18/0xa90 [lan966xpci]
This warning is triggered when a consumer is removed because the links status of its supplier is not DLDEVDRIVERBOUND and the link flag DLFLAGSYNCSTATEONLY is not set.
The topology in terms of consumers/suppliers used was the following (consumer ---> supplier):
i2c -----------> OIC ----> PCI device | ^ | | +---> pinctrl ---+
When the PCI device is removed, the OIC (interrupt controller) has to be removed. In order to remove the OIC, pinctrl and i2c need to be removed and to remove pinctrl, i2c need to be removed. The removal order is: 1) i2c 2) pinctrl 3) OIC 4) PCI device
In details, the removal sequence is the following (with 0000:01:00.0 the PCI device): driverdetach: call devicereleasedriverinternal(0000:01:00.0)... devicelinksbusy(0000:01:00.0): links->status = DLDEVUNBINDING devicelinksunbindconsumers(0000:01:00.0): 0000:01:00.0--oic link->status = DLSTATESUPPLIERUNBIND call devicereleasedriverinternal(oic)... devicelinksbusy(oic): links->status = DLDEVUNBINDING devicelinksunbindconsumers(oic): oic--pinctrl link->status = DLSTATESUPPLIERUNBIND call devicereleasedriverinternal(pinctrl)... devicelinksbusy(pinctrl): links->status = DLDEVUNBINDING devicelinksunbindconsumers(pinctrl): pinctrl--i2c link->status = DLSTATESUPPLIERUNBIND call devicereleasedriverinternal(i2c)... devicelinksbusy(i2c): links->status = DLDEVUNBINDING devicelinksnodriver(i2c)... pinctrl--i2c link->status is DLSTATESUPPLIERUNBIND oic--i2c link->status is DLSTATEACTIVE oic--i2c link->supplier->links.status is DLDEVUNBINDING
The warning is triggered by the i2c removal because the OIC (supplier) links status is not DLDEVDRIVERBOUND. Its links status is indeed set to DLDEVUNBINDING.
It is perfectly legit to have the links status set to DLDEVUNBINDING in that case. Indeed we had started to unbind the OIC which triggered the consumer unbinding and didn't finish yet when the i2c is unbound.
Avoid the warning when the supplier links status is set to DLDEVUNBINDING and thus support this removal sequence without any warnings.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the warning?
It occurs during driver removal when a consumer device is removed while its supplier's device-link status is not DL_DEV_DRIVER_BOUND, and the link does not have the DL_FLAG_SYNC_STATE_ONLY flag set. The reported topology involves chained consumer/supplier device links during PCI driver unregistration.
Is this an indication that a system has already been affected?
A system is affected if it emits the described WARNING from __device_links_no_driver during driver removal or unbinding. The provided data describes a kernel warning condition and does not identify a separate externally observable compromise indicator.
Which component is implicated by the reported call trace?
The call trace shows the issue during removal of the lan966x_pci driver, through PCI driver unregistration and driver-core device-link cleanup. The vulnerability is listed for the Linux kernel.