CVE-2026-89485

lockd: pin next file across nlm_inspect_file lock-drop

CRITICAL
9.8
CVSS Score
Published: September 11, 2026 at 07:43 PM UTC
Updated: October 19, 2026 at 09:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
CRITICAL9.8
Exploit prediction
EPSS 0.7%

Description

In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

01df9c5e918ae5559f2d96da0143f8bfbb9e61711df9c5e918ae5559f2d96da143f8bfbb9e61712.6.18
Vendor states this is fixed in 08a455f87b14c7ff22ae3fdadda62a796a3a5572 (fixed)
Vendor states this is fixed in 350087f231c11efcd288c310707c40eab63ca583 (fixed)
Vendor states this is fixed in 41f0a6d31615fcae261bf28a0aa50050dc93a401 (fixed)
Vendor states this is fixed in 526c49cff3f72c3ec74752016380c7567040581b (fixed)
Vendor states this is fixed in 550c19222c7132c888e23c9d89079ba1c9bc4cca (fixed)
Vendor states this is fixed in c24bdb7df2f34bdc38ca8a73796f5acb40f1830c (fixed)
Vendor states this is fixed in e3c413f789eaf0170275c7eba523ead73d963f30 (fixed)
Vendor states this is fixed in e999a88133654c6dfc68487fb49da5f20dfa2d4f (fixed)
Vendor states this is fixed in 2.6.18 (unaffected)
Vendor states this is fixed in 5.10.270 (unaffected)
Vendor states this is fixed in 5.15.221 (unaffected)
Vendor states this is fixed in 6.1.188 (unaffected)
Vendor states this is fixed in 6.12.109 (unaffected)
Vendor states this is fixed in 6.18.50 (unaffected)
Vendor states this is fixed in 6.6.157 (unaffected)
Vendor states this is fixed in 7.2.4 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

CVSS

9.8CRITICALLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card