Cloudanix VulnDB

CVE-2025-38311

None

CVSS

—

EPSS

0.1%

Published

Jul 10, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

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

  1. Obtain local access on a system with the iavf driver loaded
  2. Perform operations that invoke iavf_remove or trigger watchdog/reset tasks
  3. Force lock contention between crit_lock, netdev lock, and workqueue structures
  4. 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