CVE-2026-89541
CVE CVE-2026-89541EUVD EUVD-2026-76452Published 2026-09-11T19:44:18.000ZLast changed 2026-09-14T12:00:48.000ZCVSS 9.8
What the advisory describes
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_unwrap_resp_priv length checks gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with offset = (u8 *)(p) - (u8 *)head->iov_base; if (offset + opaque_len > rcv_buf->len) goto unwrap_failed; maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset, offset + opaque_len, rcv_buf); Both operands are u32 and the sum is computed in u32. A reply with opaque_len near 0xffffffff makes offset + opaque_len wrap to a small value that is below rcv_buf->len, so the bound check passes and gss_unwrap() is called with end < begin. The check also lacks a lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt header reads at ptr+4 and ptr+6 then run past the token. A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. Fix by replacing the single combined check with three guards that are safe in u32 arithmetic and that enforce the RFC 4121 minimum outer token length: if (offset > rcv_buf->len) goto unwrap_failed; if (opaque_len > rcv_buf->len - offset) goto unwrap_failed; if (opaque_len < GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed; The first guard makes the subtraction in the second guard unconditionally safe; offset is derived from a successful xdr_inline_decode() in the head kvec, so in practice it already satisfies the bound. The floor mirrors the server-side check added in commit 5b757c2e57a5 ("SUNRPC: svcauth_gss: enforce krb5 token minimum length").
Source: EUVD (ENISA), in the words of the advisory.
Products the advisory names
These come from the advisory itself, not from any check we performed.
- Linux — Linux patch: 6.1.188; patch: 5.15.221; patch: 0; 2.6.15; 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf <ebcbd2523a8524c3d24e111cdbed8e271d910269; patch: 6.12.109; 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf <89a15a50f84d32d4b99db86f957427fcbe20a99a; 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf <87831b92112c81db251d46756d65daa4f91af6a2; patch: 6.6.157; patch: 7.3-rc1; patch: 5.10.270; 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf <81fd7654a8429718adfcb2a7e03496077f547ed0; 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf <d395c30d570ca6168f0297b191709927d1258273; patch: 6.18.50; 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf <3691c4b3488d8ca046b9941e5be30c626dbbbb50; 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf <85fa6b12e8f439739ac36ef2aad925f37c8b976a; patch: 7.2.4; 2d2da60c63b67174add32f06e8d54c3a0c5cd9cf <401f6a5b338d05bb1069ad814d9f77e3c367854f
The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.
Carried in the product catalogue
An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.
- Linux — Linux
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.