CVE-2025-38311
NoneCVSS
—
EPSS
0.1%
Published
Jul 10, 2025
CISA due date
—
Cloudanix analysis
A locking mistake in a common Linux network driver could freeze the whole system when managing certain network cards.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- High
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The iavf driver used a crit_lock that created circular dependencies with workqueue and netdev locks, leading to deadlocks during VF removal, watchdog tasks, and work cancellation.
Why it matters to the business
System hangs or crashes on hosts using Intel virtual function network drivers, disrupting network connectivity and virtualized workloads across many Linux kernel deployments.
How an attack unfolds
An attacker with local access triggers iavf device removal or reset paths that contend on the crit_lock and work completion locks, reproducing the circular dependency and causing a deadlock. No named threat actors or ransomware campaigns are associated.
How to fix it
Upgrade to fixed versions: linux-lts (Alpaquita:23) 6.1.81-r0, linux-lts (Alpaquita:stream) 6.6.58-r0 or 6.12.41-r0, or kernel commit 620ab4d6215de0b25227f9fff1a8c7fb66837cb8. Reboot after update.
How to confirm the fix worked
Confirm the running kernel contains commit 620ab4d6215de0b25227f9fff1a8c7fb66837cb8 or the listed package versions; reproduce VF removal and watchdog operations while monitoring for lockdep warnings.
Typical attack path
- Obtain local access on a system with the iavf driver loaded
- Perform operations that invoke iavf_remove or trigger watchdog/reset tasks
- Force lock contention between crit_lock, netdev lock, and workqueue structures
- Induce kernel deadlock or system hang
How to detect it
Search kernel logs and dmesg for lockdep warnings referencing crit_lock, iavf_remove, watchdog_task, and work_completion; monitor for unexplained hangs during VF attach/detach or reset operations.
What your security team should do
- Apply kernel updates to fixed versions immediately on systems exposing iavf interfaces
- Prioritize patching in virtualized or cloud environments where iavf is prevalent
- Test device removal and reset paths in staging before production rollout
- Review kernel logs for prior lockdep splats involving crit_lock and iavf
The record
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] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Chainguard | hyperv-daemons-6.12 | 0 | 6.12.57-r2 |
| Chainguard | linux-aws-6.12-boot-installed | 0 | 6.12.57-r2 |
| Chainguard | linux-aws-6.12-fips-boot-installed | 0 | 6.12.57-r2 |
| Chainguard | linux-aws-6.12-headers | 0 | 6.12.57-r2 |
| Chainguard | linux-aws-6.12-modules | 0 | 6.12.57-r2 |
| Chainguard | linux-azure-6.12-boot-installed | 0 | 6.12.57-r2 |
| Chainguard | linux-azure-6.12-fips-boot-installed | 0 | 6.12.57-r2 |
| Chainguard | linux-azure-6.12-headers | 0 | 6.12.57-r2 |
| Chainguard | linux-azure-6.12-modules | 0 | 6.12.57-r2 |
| Chainguard | linux-gcp-6.12-boot-installed | 0 | 6.12.58-r0 |
| Chainguard | linux-gcp-6.12-fips-boot-installed | 0 | 6.12.57-r2 |
| Chainguard | linux-gcp-6.12-headers | 0 | 6.12.57-r2 |
| Chainguard | linux-gcp-6.12-modules | 0 | 6.12.57-r2 |
| Chainguard | linux-qemu-6.12-boot-installed | 0 | 6.12.63-r0 |
| Chainguard | linux-qemu-6.12-fips-boot-installed | 0 | 6.12.63-r0 |
| Chainguard | linux-qemu-6.12-headers | 0 | 6.12.63-r0 |
| Chainguard | linux-qemu-6.12-modules | 0 | 6.12.63-r0 |
| Chainguard | linux-vmware-6.12-boot-installed | 0 | 6.12.63-r0 |
| Chainguard | linux-vmware-6.12-fips-boot-installed | 0 | 6.12.63-r0 |
| Chainguard | linux-vmware-6.12-headers | 0 | 6.12.63-r0 |
| Chainguard | linux-vmware-6.12-modules | 0 | 6.12.63-r0 |
| Debian:12 | linux | 0 | No fix |
| Debian:13 | linux | 0 | No fix |
| Debian:14 | linux | 0 | 6.16.3-1 |
| Linux | Kernel | 6.5.0 | 6.15.3 |
| openSUSE:Leap 16.0 | dtb-aarch64 | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-64kb | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-default | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-default-base | 0 | 6.12.0-160000.6.1.160000.2.4 |
| openSUSE:Leap 16.0 | kernel-docs | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-kvmsmall | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-obs-build | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-obs-qa | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-rt | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-source | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-syms | 0 | 6.12.0-160000.6.1 |
| openSUSE:Leap 16.0 | kernel-zfcpdump | 0 | 6.12.0-160000.6.1 |
Related vulnerabilities
- CVE-2025-39910 In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc, mm/kasan… Also affects hyperv-daemons-6.12
- CVE-2025-39925 can: j1939: implement NETDEV_UNREGISTER notification handler Also affects hyperv-daemons-6.12
- CVE-2025-39905 net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Also affects hyperv-daemons-6.12
- CVE-2025-39862 In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915… Also affects hyperv-daemons-6.12
- CVE-2025-39859 In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: fix… Also affects hyperv-daemons-6.12
- CVE-2025-39834 In the Linux kernel, the following vulnerability has been resolved: net/mlx5: HWS, Fix… Also affects hyperv-daemons-6.12
- CVE-2025-39830 In the Linux kernel, the following vulnerability has been resolved: net/mlx5: HWS, Fix… Also affects hyperv-daemons-6.12
- CVE-2025-39833 In the Linux kernel, the following vulnerability has been resolved: mISDN: hfcpci: Fix… Also affects hyperv-daemons-6.12