CVE-2026-89689

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 setargetmaxslots below

se_fchannel.maxreqs, the shrink path checks three conditions before

calling freesessionslots():

1. setargetmaxslots < maxreqs  (shrink was advertised)
2. slot->slgeneration == seslot_gen  (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, sl_generation, and stores the

dangling pointer in cstate->slot. Later, nfsd4storecache_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.

NFSD4SLOTINUSE is set under nn->client_lock 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.

1. Scanning slots in the to-be-freed range for NFSD4SLOTINUSE and

    deferring the shrink if any are active.