CVE-2026-74725 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
enic: fix tx_hang_reset use-after-free on device removal
enic_remove() cancels the reset and change_mtu_work items but does not cancel tx_hang_reset. A TX timeout that fires while the device is being removed can schedule enic_tx_hang_reset() so that it runs after free_netdev(), resulting in a use-after-free.
cancel_work_sync() alone is not sufficient here: the still-live watchdog and notify paths can re-schedule these work items in the window between the cancel and unregister_netdev(). Use disable_work_sync(), which cancels the work and blocks any subsequent schedule_work() from requeuing it, and apply it to the reset and change_mtu_work items as well so the same requeue race is closed for all teardown work.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The identified vulnerability resides within the Linux kernel's enic network driver, specifically affecting the device removal sequence where a use-after-free condition can be triggered through a race condition involving hardware watchdog timers and asynchronous work items. The core technical flaw stems from an incomplete cleanup procedure during the unloading or physical removal of the network interface. While the driver correctly cancels certain scheduled tasks such as reset_work and change_mtu_work, it fails to cancel the tx_hang_reset work item. This oversight creates a critical window where the hardware watchdog timer may still be active and capable of triggering a transmission timeout event even after the kernel has initiated the device teardown process.
When a TX timeout occurs during this fragile removal phase, the driver schedules enic_tx_hang_reset() to handle the hang condition. However, because the work item was not properly cancelled prior to freeing network device resources via free_netdev(), there is no guarantee that the scheduled work will complete before memory deallocation occurs. Consequently, if the kernel scheduler executes this deferred function after the net_device structure has been freed, it results in a use-after-free vulnerability. This type of error allows for potential out-of-bounds reads or writes depending on how the stale pointer is dereferenced within the hang reset routine, which can lead to system instability, kernel panics, or potentially exploitable code execution scenarios if an attacker can influence the timing and state of the network interface.
The operational impact of this vulnerability includes severe stability issues for systems relying on enic-based virtualized networking interfaces, commonly found in environments utilizing Cisco VIC hardware within cloud infrastructure. A successful exploitation could result in a denial of service through kernel crashes or data corruption if memory reuse patterns allow malicious control flow redirection. The root cause is classified under CWE-416 Use After Free, highlighting the failure to properly manage object lifecycles during resource teardown. Furthermore, this scenario aligns with ATT&CK techniques related to privilege escalation via local exploitation of race conditions in kernel drivers, as it involves manipulating timing windows within privileged code paths to achieve unintended memory access.
To mitigate this vulnerability and prevent similar issues across other device removal sequences, the fix implements a more robust synchronization mechanism using disable_work_sync(). Unlike cancel_work_sync(), which only cancels currently pending work items but does not prevent new ones from being scheduled during the cancellation window, disable_work_sync() actively blocks any subsequent schedule_work calls. This ensures that once the disabling process begins, no further re-queuing of these critical teardown tasks can occur until explicitly enabled again. The patch applies this stricter synchronization to all relevant work items including reset and change_mtu_work, thereby closing race conditions across the entire device removal lifecycle. System administrators should ensure their kernels are updated with patches addressing this specific enic driver flaw to maintain system integrity during network interface hot-unplug operations or driver reloads.