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.

An update of the linux package has been released.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2025-39945)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
270566	Photon OS 4.0: Linux PHSA-2025-4.0-0887	Nessus	PhotonOS Local Security Checks	medium
270412	Photon OS 5.0: Linux PHSA-2025-5.0-0643	Nessus	PhotonOS Local Security Checks	high
269455	Linux Distros Unpatched Vulnerability : CVE-2025-39945	Nessus	Misc.	high

Detections

Analytics

CVE-2025-39945

high

Tenable Plugins

medium

high

high