GHSA-49VG-HXCF-G87M
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-13 09:32In 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():
- se_target_maxslots < maxreqs (shrink was advertised)
- slot->sl_generation == se_slot_gen (slot is up-to-date)
- 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.
{
"affected": [],
"aliases": [
"CVE-2026-89689"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T20:19:55Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: don\u0027t free session slots that are still in use\n\nnfsd4_sequence() can free the very slot it is currently processing.\nWhen the session shrinker has reduced se_target_maxslots below\nse_fchannel.maxreqs, the shrink path checks three conditions before\ncalling free_session_slots():\n\n 1. se_target_maxslots \u003c maxreqs (shrink was advertised)\n 2. slot-\u003esl_generation == se_slot_gen (slot is up-to-date)\n 3. seq-\u003emaxslots \u003c= se_target_maxslots (client acknowledges)\n\nHowever, seq-\u003eslotid is never checked against se_target_maxslots.\nA client using a slot in the range [se_target_maxslots, maxreqs) can\nsatisfy all three conditions: its slot has the current generation\n(set by a prior SEQUENCE), and it sends sa_highest_slotid \u003c=\nse_target_maxslots to acknowledge the reduction.\n\nfree_session_slots() then kfrees every slot at index \u003e=\nse_target_maxslots, including the caller\u0027s own slot. The function\ncontinues to write sl_seqid, sl_flags, sl_generation, and stores the\ndangling pointer in cstate-\u003eslot. Later, nfsd4_store_cache_entry()\ncopies up to maxresp_cached bytes of the compound reply into the freed\nsl_data[] array, corrupting whatever slab object now occupies that\naddress.\n\nAdditionally, a concurrent thread processing SEQUENCE on a different\nhigh-numbered slot can have its slot freed out from under it.\nNFSD4_SLOT_INUSE is set under nn-\u003eclient_lock before the lock is\nreleased, so any concurrent thread past SEQUENCE will have its slot\nmarked. However, free_session_slots() does not check NFSD4_SLOT_INUSE\nbefore freeing.\n\nFix both problems by:\n 1. Checking that the current request\u0027s slotid is below the shrink\n boundary.\n 2. Scanning slots in the to-be-freed range for NFSD4_SLOT_INUSE and\n deferring the shrink if any are active.",
"id": "GHSA-49vg-hxcf-g87m",
"modified": "2026-09-13T09:32:27Z",
"published": "2026-09-11T21:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89689"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72d40b103bb03f0124d3a3c8f71a30cbafaf6afa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b449b134e7762ddf98653a4b1d3e76d2d212ea64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5d22e372f4ac3eb287037a488c29691d52a6330"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.