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"
}
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
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.