cbcvebase.
CVE-2025-38311
published 2025-07-10

CVE-2025-38311: In the Linux kernel, the following vulnerability has been resolved: iavf: get rid of the crit lock Get rid of the crit lock. That frees us from the error prone…

PriorityP417medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.10%
0.8th percentile
In the Linux kernel, the following vulnerability has been resolved: iavf: get rid of the crit lock Get rid of the crit lock. That frees us from the error prone logic of try_locks. Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were protected by it already - replace crit lock by netdev lock when it was not the case. Lockdep reports that we should cancel the work under crit_lock [splat1], and that was the scheme we have mostly followed since [1] by Slawomir. But when that is done we still got into deadlocks [splat2]. So instead we should look at the bigger problem, namely "weird locking/scheduling" of the iavf. The first step to fix that is to remove the crit lock. I will followup with a -next series that simplifies scheduling/tasks. Cancel the work without netdev lock (weird unlock+lock scheme), to fix the [splat2] (which would be totally ugly if we would kept the crit lock). Extend protected part of iavf_watchdog_task() to include scheduling more work. Note that the removed comment in iavf_reset_task() was misplaced, it belonged to inside of the removed if condition, so it's gone now. [splat1] - w/o this patch - The deadlock during VF removal: WARNING: possible circular locking dependency detected sh/3825 is trying to acquire lock: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470 but task is already holding lock: (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf] which lock already depends on the new lock. [splat2] - when cancelling work under crit lock, w/o this series, see [2] for the band aid attempt WARNING: possible circular locking dependency detected sh/3550 is trying to acquire lock: ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90 but task is already holding lock: (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf] which lock already depends on the new lock. [1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation") [2

Affected

23 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.16.3-1 (forky)linux 6.16.3-1 (forky)
linuxlinux
linuxlinux
linuxlinux
linuxlinux>= 6.1.42 < 6.26.2
linuxlinux>= 6.4.7 < 6.56.5
linuxlinux>= d1639a17319ba78a018280cd2df6577a7e5d9fab < 620ab4d6215de0b25227f9fff1a8c7fb66837cb8620ab4d6215de0b25227f9fff1a8c7fb66837cb8
linuxlinux>= d1639a17319ba78a018280cd2df6577a7e5d9fab < 120f28a6f314fef7f282c99f196923fe44081cad120f28a6f314fef7f282c99f196923fe44081cad
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.16.3-16.16.3-1
linuxlinux_kernel>= 6.1.42 < 6.26.2
linuxlinux_kernel>= 6.4.7 < 6.56.5
linuxlinux_kernel>= 6.5.1 < 6.15.36.15.3
msrcazl3_kernel_6.6.104.2-4_on_azure_linux_3.0
msrcazl3_kernel_6.6.112.1-2_on_azure_linux_3.0
msrcazl3_kernel_6.6.117.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.119.3-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.119.3-3_on_azure_linux_3.0
msrcazl3_kernel_6.6.121.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.126.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.130.1-3_on_azure_linux_3.0
msrcazl3_kernel_6.6.96.2-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.96.2-2_on_azure_linux_3.0

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_msrc7.0HIGH
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.