CVE-2025-39945

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cnic: Fix use-after-free bugs in cnic_delete_task<br /> <br /> The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),<br /> which does not guarantee that the delayed work item &amp;#39;delete_task&amp;#39; has<br /> fully completed if it was already running. Additionally, the delayed work<br /> item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only<br /> blocks and waits for work items that were already queued to the<br /> workqueue prior to its invocation. Any work items submitted after<br /> flush_workqueue() is called are not included in the set of tasks that the<br /> flush operation awaits. This means that after the cyclic work items have<br /> finished executing, a delayed work item may still exist in the workqueue.<br /> This leads to use-after-free scenarios where the cnic_dev is deallocated<br /> by cnic_free_dev(), while delete_task remains active and attempt to<br /> dereference cnic_dev in cnic_delete_task().<br /> <br /> A typical race condition is illustrated below:<br /> <br /> CPU 0 (cleanup) | CPU 1 (delayed work callback)<br /> cnic_netdev_event() |<br /> cnic_stop_hw() | cnic_delete_task()<br /> cnic_cm_stop_bnx2x_hw() | ...<br /> cancel_delayed_work() | /* the queue_delayed_work()<br /> flush_workqueue() | executes after flush_workqueue()*/<br /> | queue_delayed_work()<br /> cnic_free_dev(dev)//free | cnic_delete_task() //new instance<br /> | dev = cp-&gt;dev; //use<br /> <br /> Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure<br /> that the cyclic delayed work item is properly canceled and that any<br /> ongoing execution of the work item completes before the cnic_dev is<br /> deallocated. Furthermore, since cancel_delayed_work_sync() uses<br /> __flush_work(work, true) to synchronously wait for any currently<br /> executing instance of the work item to finish, the flush_workqueue()<br /> becomes redundant and should be removed.<br /> <br /> This bug was identified through static analysis. To reproduce the issue<br /> and validate the fix, I simulated the cnic PCI device in QEMU and<br /> introduced intentional delays — such as inserting calls to ssleep()<br /> within the cnic_delete_task() function — to increase the likelihood<br /> of triggering the bug.