CVE-2026-89689: nfsd: don't free session slots that are still in use
In the Linux kernel, the following vulnerability has been resolved:
nfsd: don't free session slots that are still in use
nfsd4sequence() can free the very slot it is currently processing. When the session shrinker has reduced setargetmaxslots below sefchannel.maxreqs, the shrink path checks three conditions before calling freesessionslots():
1. setargetmaxslots < maxreqs (shrink was advertised) 2. slot->slgeneration == seslotgen (slot is up-to-date) 3. seq->maxslots <= setargetmaxslots (client acknowledges)
However, seq->slotid is never checked against setargetmaxslots. A client using a slot in the range [setargetmaxslots, maxreqs) can satisfy all three conditions: its slot has the current generation (set by a prior SEQUENCE), and it sends sahighestslotid <= setargetmaxslots to acknowledge the reduction.
freesessionslots() then kfrees every slot at index >= setargetmaxslots, including the caller's own slot. The function continues to write slseqid, slflags, slgeneration, and stores the dangling pointer in cstate->slot. Later, nfsd4storecacheentry() copies up to maxrespcached bytes of the compound reply into the freed sldata[] 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. NFSD4SLOTINUSE is set under nn->clientlock before the lock is released, so any concurrent thread past SEQUENCE will have its slot marked. However, freesessionslots() does not check NFSD4SLOTINUSE 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 NFSD4SLOTINUSE and deferring the shrink if any are active.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux kernel systems running the NFS server component (nfsd) are exposed when session slot shrinking reduces se_target_maxslots below the session's negotiated maximum request slots.
What does a client need to do to trigger the unsafe free?
A client must use a slot whose ID is at least se_target_maxslots but below maxreqs, while that slot has the current generation. It must also send a SEQUENCE request that acknowledges the reduced slot limit by reporting sa_highest_slotid no greater than se_target_maxslots.
What is the impact after the affected slot is freed?
The server continues using the freed slot and stores its dangling pointer in cstate->slot. When it later caches a compound reply, it can copy response data into the freed sl_data array and corrupt freed memory.