CVE-2025-39945
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-04

Last updated on: 2025-10-06

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: cnic: Fix use-after-free bugs in cnic_delete_task The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task(). A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-04
Last Modified
2025-10-06
Generated
2026-05-07
AI Q&A
2025-10-04
EPSS Evaluated
2026-05-05
NVD
CVE-2025-39945
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free bug in the Linux kernel's cnic driver. It occurs because the code uses cancel_delayed_work() which does not guarantee that a delayed work item called 'delete_task' has fully completed if it was already running. Since the delayed work item is cyclic and flush_workqueue() only waits for previously queued work, new work items can still be active after the device is freed. This leads to a scenario where the cnic_dev structure is deallocated while 'delete_task' still tries to access it, causing use-after-free errors. The fix replaces cancel_delayed_work() with cancel_delayed_work_sync() to ensure the work item is fully canceled and completed before freeing the device.


How can this vulnerability impact me? :

This vulnerability can lead to use-after-free conditions in the Linux kernel, which may cause system instability, crashes, or potential kernel memory corruption. Such issues can be exploited to cause denial of service or potentially escalate privileges if an attacker can trigger the race condition.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the cnic driver uses cancel_delayed_work_sync() instead of cancel_delayed_work() in the cnic_cm_stop_bnx2x_hw() function. This ensures that the cyclic delayed work item is properly canceled and any ongoing execution completes before the cnic_dev is deallocated, preventing use-after-free bugs. Additionally, remove the flush_workqueue() call in that function as it becomes redundant.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart