CVE-2026-97479 in Linux
Summary
by MITRE • 09/24/2026
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 __device_links_no_driver+0xcc/0xfc ... Call trace: __device_links_no_driver+0xcc/0xfc (P) device_links_driver_cleanup+0xa8/0xf0 device_release_driver_internal+0x208/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c driver_detach+0xa0/0x12c bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 pci_unregister_driver+0x20/0x9c lan966x_pci_driver_exit+0x18/0xa90 [lan966x_pci]
This warning is triggered when a consumer is removed because the links status of its supplier is not DL_DEV_DRIVER_BOUND and the link flag DL_FLAG_SYNC_STATE_ONLY 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): driver_detach: call device_release_driver_internal(0000:01:00.0)... device_links_busy(0000:01:00.0): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(0000:01:00.0): 0000:01:00.0--oic link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(oic)... device_links_busy(oic): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(oic): oic--pinctrl link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(pinctrl)... device_links_busy(pinctrl): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(pinctrl): pinctrl--i2c link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(i2c)... device_links_busy(i2c): links->status = DL_DEV_UNBINDING __device_links_no_driver(i2c)... pinctrl--i2c link->status is DL_STATE_SUPPLIER_UNBIND oic--i2c link->status is DL_STATE_ACTIVE oic--i2c link->supplier->links.status is DL_DEV_UNBINDING
The warning is triggered by the i2c removal because the OIC (supplier) links status is not DL_DEV_DRIVER_BOUND. Its links status is indeed set to DL_DEV_UNBINDING.
It is perfectly legit to have the links status set to DL_DEV_UNBINDING 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 DL_DEV_UNBINDING and thus support this removal sequence without any warnings.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel device driver core subsystem manages complex dependency relationships between hardware components through a consumer-supplier model, where devices rely on others for resources such as interrupts or clock signals. A specific vulnerability was identified in the handling of these dependencies during the unbinding phase of drivers. The issue manifests when removing a device that acts as a supplier to another device which is currently being removed due to its own dependency chain. Specifically, the warning __device_links_no_driver is triggered incorrectly because it checks if the supplier's link status is DL_DEV_DRIVER_BOUND and fails to account for the transient state where the supplier itself is in the process of unbinding. This results in a false positive kernel warning that disrupts system logs and can cause confusion during debugging or automated monitoring systems, although it does not typically lead to data corruption or security breaches directly but indicates improper handling of internal synchronization states.
The technical flaw resides in the logic within drivers/base/core.c at the function __device_links_no_driver. When a consumer device is being unbound, the kernel checks if its supplier still has an active driver bound by verifying the link status. However, during recursive removal sequences where multiple devices are torn down simultaneously or sequentially due to dependency chains, the supplier may have already transitioned its state to DL_DEV_UNBINDING but not yet completed all cleanup operations. The existing code did not consider this intermediate unbinding state as a valid condition for skipping the warning check. Consequently, when an i2c controller was removed because its parent interrupt controller (OIC) was being detached from a PCI device, the OIC's link status was DL_DEV_UNBINDING rather than DL_DEV_DRIVER_BOUND. The code interpreted this absence of a bound driver as an error condition requiring a warning, despite it being a legitimate part of the teardown process for interdependent devices like pinctrl and i2c controllers linked to an interrupt controller on a PCI bus.
From an operational perspective, this vulnerability affects system stability observability rather than direct security or availability in most cases. The primary impact is the generation of spurious kernel warnings that clutter dmesg output and can trigger false alarms in monitoring systems designed to detect critical errors. In environments with strict logging policies or automated alerting based on kernel warning levels, these messages could lead to unnecessary incident response actions or system downtime if administrators misinterpret them as signs of deeper hardware failures or race conditions. Furthermore, the presence of such warnings complicates troubleshooting efforts by obscuring genuine issues amidst noise generated during normal driver unload operations for complex peripheral hierarchies involving PCI devices, interrupt controllers, pin control subsystems, and I2C buses.
To mitigate this issue, the kernel developers updated the condition in __device_links_no_driver to explicitly check if the supplier's link status is DL_DEV_UNBINDING. By treating this state as a valid scenario where no warning should be issued, the code correctly acknowledges that the consumer device is being removed concurrently with its supplier due to dependency constraints. This change aligns the driver core logic with the actual lifecycle states of devices during unbinding sequences. The fix ensures that warnings are only generated when there is an actual mismatch in expected versus actual driver binding status outside of controlled teardown operations.
This vulnerability can be categorized under CWE-390, Detection of Error Condition Without Action, as it involves detecting a condition (missing bound driver) and reacting with a warning even though the situation is benign within the context of device unbinding. In terms of MITRE ATT&CK mapping, this does not represent an exploitable attack vector but rather falls under T1562, Impair Defenses, specifically related to disabling or modifying security tools if one considers logging mechanisms as defensive controls that are being degraded by false positives. However, it is primarily a software defect in state management logic within the operating system kernel's device driver framework. The resolution ensures robust handling of dependency graphs during dynamic configuration changes and module unloading, maintaining clean operational logs for administrators and automated systems alike.