CVE-2025-39945

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.

Gravité et risque d'exploitation

CVE-2025-39945 obtient un score CVSS de 7.8/10, soit une gravité élevée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.16 %, ce qui la place devant 4.5 % des CVE référencées.

Que faire ?

• Vérifiez si Linux (versions <cfa7d9b1e3a8604afc84e9e51d789c29574fb216, 5.4.300, <=6.1.*, <=6.12.*, 2.6.37, <=6.16.*, <2.6.37, 6.12.49, 6.1.154, 6.17, 0, <6e33a7eed587062ca8161ad1f4584882a860d697, 6.16.9, fdf24086f4752aee5dfb40143c736250df017820, <fde6e73189f40ebcf0633aed2b68e731c25f3aa3, <0627e1481676669cae2df0d85b5ff13e7d24c390, <7b6a5b0a6b392263c3767fc945b311ea04b34bbd, <=5.10.*, 5.15.194, <=6.6.*, <=5.4.*, 6.6.108, 5.10.245, <8eeb2091e72d75df8ceaa2172638d61b4cf8929a, <=*, <e1fcd4a9c09feac0902a65615e866dbf22616125, <=5.15.*, <0405055930264ea8fd26f4131466fa7652e5e47d) est présent sur votre parc.
• Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
• À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
• Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références

• https://git.kernel.org/stable/c/fde6e73189f40ebcf0633aed2b68e731c25f3aa3
• https://git.kernel.org/stable/c/7b6a5b0a6b392263c3767fc945b311ea04b34bbd
• https://git.kernel.org/stable/c/0405055930264ea8fd26f4131466fa7652e5e47d
• https://git.kernel.org/stable/c/e1fcd4a9c09feac0902a65615e866dbf22616125
• https://git.kernel.org/stable/c/8eeb2091e72d75df8ceaa2172638d61b4cf8929a
• https://git.kernel.org/stable/c/6e33a7eed587062ca8161ad1f4584882a860d697
• https://git.kernel.org/stable/c/0627e1481676669cae2df0d85b5ff13e7d24c390
• https://git.kernel.org/stable/c/cfa7d9b1e3a8604afc84e9e51d789c29574fb216