CVE-2024-26802 in Linux
Summary
by MITRE • 04/04/2024
In the Linux kernel, the following vulnerability has been resolved:
stmmac: Clear variable when destroying workqueue
Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized.
This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped, it will cause kernel/module panic.
To secure against this possible crash, set workqueue variable to NULL when destroying workqueue.
Log/backtrace from crash goes as follows: [88.031977]------------[ cut here ]------------
[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out
[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398
[88.032251]---[ end trace e70de432e4d5c2c0 ]---
[88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter.
[88.036359]------------[ cut here ]------------
[88.036519]Call trace:
[88.036523] flush_workqueue+0x3e4/0x430
[88.036528] drain_workqueue+0xc4/0x160
[88.036533] destroy_workqueue+0x40/0x270
[88.036537] stmmac_fpe_stop_wq+0x4c/0x70
[88.036541] stmmac_release+0x278/0x280
[88.036546] __dev_close_many+0xcc/0x158
[88.036551] dev_close_many+0xbc/0x190
[88.036555] dev_close.part.0+0x70/0xc0
[88.036560] dev_close+0x24/0x30
[88.036564] stmmac_service_task+0x110/0x140
[88.036569] process_one_work+0x1d8/0x4a0
[88.036573] worker_thread+0x54/0x408
[88.036578] kthread+0x164/0x170
[88.036583] ret_from_fork+0x10/0x20
[88.036588]---[ end trace e70de432e4d5c2c1 ]---
[88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/04/2025
The vulnerability CVE-2024-26802 affects the stmmac network driver in the Linux kernel, specifically addressing an improper handling of workqueue cleanup during driver suspension and resume operations. This flaw stems from a logical inconsistency in how the driver manages workqueue resources when transitioning between operational states. The issue manifests when the driver attempts to destroy a workqueue that may not have been properly initialized, leading to a kernel panic due to a NULL pointer dereference. The root cause lies in the destroy_workqueue() function which drains the queue but fails to set the workqueue variable to NULL, creating a scenario where subsequent operations attempt to access a stale reference. This vulnerability directly relates to CWE-476 which describes NULL pointer dereference conditions, and falls under the ATT&CK technique T1489 which involves modifying system images to disrupt system operations.
The operational impact of this vulnerability becomes apparent during driver resume operations when the stmmac_resume() function processes failed hardware setup scenarios. When the DMA engine fails to initialize, the driver continues with the resume process but skips workqueue initialization, leaving the workqueue variable in an inconsistent state. Subsequently, when the driver attempts to reset the adapter during error handling, it calls destroy_workqueue() on what may be a non-initialized workqueue, causing the kernel to crash. The stack trace reveals a clear progression from network interface timeouts, through watchdog warnings, to the actual crash point where flush_workqueue() attempts to access a NULL pointer at virtual address 0x0000000000000004. This represents a critical failure mode that can result in complete system instability and requires immediate remediation to prevent unauthorized denial of service attacks against network infrastructure.
The fix implemented addresses this issue by ensuring that the workqueue variable is explicitly set to NULL immediately after destroy_workqueue() is called, preventing subsequent operations from attempting to access invalid memory references. This remediation follows established best practices for resource management in kernel space and aligns with the principle of defensive programming where all pointers are properly initialized and cleared after use. The solution specifically targets the stmmac_fpe_stop_wq() function which is called during cleanup operations, ensuring that the workqueue state is properly managed regardless of whether the DMA engine initialization succeeded or failed. This patch demonstrates the importance of proper state management in kernel drivers and highlights the need for comprehensive error handling in complex hardware initialization sequences where dependencies between subsystems can lead to inconsistent states. The vulnerability represents a classic example of resource lifecycle management issues that can be exploited to cause system crashes, emphasizing the critical nature of proper kernel module cleanup procedures.