GPU VulnDB

Database/Control plane, storage & DevOps

Linux nfsd: session slot shrinker frees the slot in use, corrupting the slab with reply data

CVSS 9.8CVE-2026-89689Control plane, storage & DevOpscurated

Impact

The session shrink path never checked the current request's slotid against se_target_maxslots, so a client using a slot above the shrink boundary can satisfy every guard and have free_session_slots() kfree the slot it is being served on. nfsd then keeps writing sl_seqid, sl_flags and sl_generation to freed memory, stores the dangling pointer in cstate->slot, and nfsd4_store_cache_entry() later copies up to maxresp_cached bytes of the compound reply into the freed sl_data[] - a client-controlled write into whatever slab object now occupies that address. The shrinker can also free a high-numbered slot out from under a concurrent SEQUENCE because NFSD4_SLOT_INUSE was not consulted. This is the strongest of the nfsd bugs in this batch: a controlled heap write from an authenticated client against the storage server the whole cluster mounts.

Who can reach it

An NFSv4.1/4.2 client that can mount the export and choose its slot id, once the session shrinker has reduced the target slot count under memory pressure. Ordinary client authentication; no server-side privilege.

What to do

Patch the NFS server kernel with one of the linked stable commits and reboot the server - the fix bounds the caller's slotid and defers the shrink when any slot in the range is NFSD4_SLOT_INUSE. Treat this one as the reason to open the window rather than waiting for the next routine kernel roll; there is no supported way to disable the session shrinker.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.