Read the docs
TI-2025-25650 Aliases CVE-2025-38311GHSA-g72f-6g67-w739

iavf: get rid of the crit lock

Priority LOW 24CWE-667Published · Updated

Key facts

Attack vector
Local
Privileges required
Low
User interaction
None
Attack complexity
Low
Impact type
Denial of service
Confidentiality · integrity · availability
None · None · High
Fix status
Partial Red Hat: 3 without a fix

Attack profile from CVSS 3.1 · NVD. Fix status from CNA and Red Hat. Impact type from CWE-667 and the CVSS impact.

Summary

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

Why it matters now

Exploitation None reported CISA SSVC · not in CISA KEV
EPSS 0.0011 1st percentileScored 2026-11-07
Fix Partial Linux (Linux): 6.2, 6.5, 6.15.3 +1Red Hat: 3 without a fix

SSVC decision points

CISA ADP · SSVC 2.0.3

Exploitation
None
Automatable
No
Technical impact
Partial

The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.

Affected products

VendorProductAffected versionsFixed inStatusSource
LinuxLinux6.1.42 to before 6.2; 6.4.7 to before 6.56.2, 6.5Patch availableCNA
LinuxLinux6.5 and later6.15.3, 6.16Patch availableCNA
  • Linux VendorLinux Affected 6.1.42 to before 6.2; 6.4.7 to before 6.5 Fixed in 6.2, 6.5 Patch available CNA
  • Linux VendorLinux Affected 6.5 and later Fixed in 6.15.3, 6.16 Patch available CNA

CPE configurations NVD · 7

CPEVersionsRoleVendor
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*6.1.42 to before 6.2; 6.4.7 to before 6.5; 6.5.1 to before 6.15.3VulnerableLinux
cpe:2.3:o:linux:linux_kernel:6.5:-:*:*:*:*:*:*6.5VulnerableLinux
cpe:2.3:o:linux:linux_kernel:6.5:rc3:*:*:*:*:*:*6.5 rc3VulnerableLinux
cpe:2.3:o:linux:linux_kernel:6.5:rc4:*:*:*:*:*:*6.5 rc4VulnerableLinux
cpe:2.3:o:linux:linux_kernel:6.5:rc5:*:*:*:*:*:*6.5 rc5VulnerableLinux
cpe:2.3:o:linux:linux_kernel:6.5:rc6:*:*:*:*:*:*6.5 rc6VulnerableLinux
cpe:2.3:o:linux:linux_kernel:6.5:rc7:*:*:*:*:*:*6.5 rc7VulnerableLinux
  • cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* Versions 6.1.42 to before 6.2; 6.4.7 to before 6.5; 6.5.1 to before 6.15.3 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:6.5:-:*:*:*:*:*:* Versions 6.5 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:6.5:rc3:*:*:*:*:*:* Versions 6.5 rc3 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:6.5:rc4:*:*:*:*:*:* Versions 6.5 rc4 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:6.5:rc5:*:*:*:*:*:* Versions 6.5 rc5 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:6.5:rc6:*:*:*:*:*:* Versions 6.5 rc6 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:6.5:rc7:*:*:*:*:*:* Versions 6.5 rc7 Vulnerable ·Linux

Remediation

  • Fix · CNA Linux (Linux) Fixed in 6.2, 6.5
  • Fix · CNA Linux (Linux) Fixed in 6.15.3, 6.16

Vendor assessments

Red Hat

Red Hat rating: Moderate. Red Hat's page for this CVE →

ProductStatusPlan or fix
Red Hat Enterprise Linux 10AffectedNo fix yet: Fix deferred
Red Hat Enterprise Linux 8AffectedNo fix yet: Fix deferred
Red Hat Enterprise Linux 9AffectedNo fix yet: Fix deferred
Not affected: 2 products
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7

Timeline

  1. 2026-10-02 Threatist record created from CVE-2025-38311
  2. 2026-10-03 Alias added: GHSA-g72f-6g67-w739
  3. 2026-11-05 CISA SSVC decision points changed

References

  • TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
  • TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
  • TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
  • TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
  • TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
  • TI-2021-05514 Heap Out-Of-Bounds Write in Netfilter IP6T_SO_SET_REPLACE KEVCVSS 3.1HIGH 8.3
See all 15278 →

Sources