PT-2026-90383 · Linux · Linux
CVE-2026-89667
·
Published
2026-09-11
·
Updated
2026-09-11
CVSS v3.1
8.1
High
| Vector | AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
In the Linux kernel, the following vulnerability has been resolved:
nfsd: close shrinker/GC/fsnotify vs per-net shutdown race in filecache
The shrinker, GC worker, and fsnotify/lease callbacks can unhash an
nfsd file from the rhashtable and then call
nfsd file dispose list delayed() to move it to the per-net dispose list.
If nfsd file cache shutdown net() runs concurrently, its rhashtable walk
misses the already-unhashed file, and its drain of the per-net dispose
list can run before the file has been queued. The file then sits on
the per-net list with no thread to drain it, leaking both the file and
its associated state.
The GC worker and shrinker already hold nfsd gc lock while walking the
LRU, but in the original code they release it before calling
nfsd file dispose list delayed(). The fsnotify/lease path
(nfsd file close inode) has no synchronization at all.
Fix this by:
-
Widening nfsd gc lock in both nfsd file gc() and nfsd file lru scan() to cover the nfsd file dispose list delayed() call.
-
Wrapping nfsd file close inode() in nfsd gc lock so that all three callers of nfsd file dispose list delayed() hold the lock.
-
Adding a spin lock/unlock(nfsd gc lock) barrier in nfsd file cache shutdown net() after the purge, so that any in-progress disposal has fully completed before the per-net list is drained.
All operations inside the lock are non-sleeping (rhashtable lookups,
atomic bit/refcount ops, list moves, svc wake up), so the spinlock is
appropriate.
Fix
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux