CVE-2026-89689
largeUse-After-Free in Linux Kernel nfsd NFSv4 Session Slot Handling
The Linux kernel's NFS server (nfsd) contains a use-after-free in NFSv4.x session slot management: when the session shrinker reduces the slot budget (se_target_maxslots below maxreqs), a malicious NFS client can send a SEQUENCE operation on a high-numbered slot while reporting sa_highest_slotid equal to the shrink boundary, satisfying all three shrink conditions and causing nfsd to free the very slot it is currently processing (or one in use by a concurrent thread). nfsd then continues writing sequence state into the freed slot and nfsd4_store_cache_entry() copies the cached compound reply into the freed sl_data[] array, corrupting whatever slab object now occupies that kernel memory. An attacker who can act as an NFS client to an affected server gains kernel heap corruption, which at minimum enables denial of service (kernel panic) and plausibly kernel-level privilege escalation or code execution. Any Linux system running nfsd and exporting filesystems via NFSv4.x to clients on a reachable network is affected, with the highest risk on servers reachable by untrusted or partially trusted clients. No public proof of concept exists and no in-the-wild exploitation has been observed as of this analysis.
What to do: Apply kernel updates from your distribution that contain the nfsd session-slot fix as soon as stable/LTS packages carrying it are released. Until patched, restrict access to the NFS service (TCP 2049) to trusted client subnets via firewall rules and treat any client with mount access as capable of triggering kernel memory corruption. Monitor NFS servers' dmesg/kernel logs for slab corruption warnings or oopses in nfsd4_sequence/free_session_slots paths, which would indicate exploitation attempts.
| Linux kernel (nfsd) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: nfsd: don't free session slots that are still in use nfsd4_sequence() can free the very slot it is currently processing. When the session shrinker has reduced se_target_maxslots below se_fchannel.maxreqs, the shrink path checks three conditions before calling free_session_slots(): 1. se_target_maxslots sl_generation == se_slot_gen (slot is up-to-date) 3. seq->maxslots slotid is never checked against se_target_maxslots. A client using a slot in the range [se_target_maxslots, maxreqs) can satisfy all three conditions: its slot has the current generation (set by a prior SEQUENCE), and it sends sa_highest_slotid = se_target_maxslots, including the caller's own slot. The function continues to write sl_seqid, sl_flags, sl_generation, and stores the dangling pointer in cstate->slot. Later, nfsd4_store_cache_entry() copies up to maxresp_cached bytes of the compound reply into the freed sl_data[] array, corrupting whatever slab object now occupies that address. Additionally, a concurrent thread processing SEQUENCE on a different high-numbered slot can have its slot freed out from under it. NFSD4_SLOT_INUSE is set under nn->client_lock before the lock is released, so any concurrent thread past SEQUENCE will have its slot marked. However, free_session_slots() does not check NFSD4_SLOT_INUSE before freeing. Fix both problems by: 1. Checking that the current request's slotid is below the shrink boundary. 2. Scanning slots in the to-be-freed range for NFSD4_SLOT_INUSE and deferring the shrink if any are active.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.