DEBIAN-CVE-2026-89689

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.