GHSA-7GQJ-379Q-CVHQ
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-14 15:32In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow
xdr_buf_trim() trims len bytes from the tail of an xdr_buf by
walking the tail, pages, and head iovecs. Each per-section step
uses min_t() so it never removes more bytes than that section
holds, but the final accounting at the fix_len label subtracts the
total bytes actually consumed from buf->len without any clamp:
fix_len:
buf->len -= (len - trim);
When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state:
buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip;
buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip);
xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip);
buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder.
Fix by clamping the decrement so buf->len bottoms out at zero:
buf->len -= min_t(unsigned int, buf->len, len - trim);
On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.
{
"affected": [],
"aliases": [
"CVE-2026-89551"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T20:19:38Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: xdr_buf_trim: clamp buf-\u003elen to avoid underflow\n\nxdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by\nwalking the tail, pages, and head iovecs. Each per-section step\nuses min_t() so it never removes more bytes than that section\nholds, but the final accounting at the fix_len label subtracts the\ntotal bytes actually consumed from buf-\u003elen without any clamp:\n\n fix_len:\n buf-\u003elen -= (len - trim);\n\nWhen the caller has set buf-\u003elen to a value smaller than the sum\nof the iov_lens, (len - trim) can exceed buf-\u003elen and the unsigned\nsubtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches\nxdr_buf_trim() in exactly that state:\n\n buf-\u003ehead[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip;\n buf-\u003elen = len - (GSS_KRB5_TOK_HDR_LEN + headskip);\n xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip);\n\nbuf-\u003elen is a small wire-derived value while the iov_lens are at\npage scale, so the per-section loops legitimately consume far more\nbytes than buf-\u003elen records. The wrapped buf-\u003elen then propagates\nas the authoritative stream bound into every downstream XDR\ndecoder.\n\nFix by clamping the decrement so buf-\u003elen bottoms out at zero:\n\n buf-\u003elen -= min_t(unsigned int, buf-\u003elen, len - trim);\n\nOn the normal path where the iov_lens sum to buf-\u003elen, (len - trim)\nis always \u003c= buf-\u003elen and the result is identical to before. No\ncallers change behavior outside the underflow case.",
"id": "GHSA-7gqj-379q-cvhq",
"modified": "2026-09-14T15:32:28Z",
"published": "2026-09-11T21:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89551"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3f491306dcb673ff5e78e1044ba450c58978774e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4bf59cb0ea5b0ddfbc46a1dc2fa78fc8b9986ce4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85e9602650e9df07190abe817cee3b4d9bc3df17"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3d77bcd974b8625d16bddf448cb3a1b5e37049c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a924ac4c78afab71bf82641afa3b62e0c4a8b55e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad0cce80d4af2f74674e8b635d97aa3880e83da8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6267cccd7b05cc514e57f2160aa8db85f5c2701"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa16bbe987b47e771e52eeb1b4540f18d92496ac"
}
],
"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.