CVE-2026-89550
moderateLinux kernel NFS svcauth_gss divide-by-zero via short krb5 privacy token
The Linux kernel's SUNRPC GSS authentication code (svcauth_gss_unwrap_priv()) validates only an upper bound on the wire-supplied token length, so a krb5 'privacy' (sealed) token with a length of 16 bytes or less — shorter than or equal to the mandatory 16-byte RFC 4121 header — is passed into gss_unwrap(). In the krb5 v2 unwrap path, gss_krb5_unwrap_v2() reads header fields past the end of the truncated token and calls rotate_left() before any integrity check, which can hit a division by zero when the sub-buffer length is driven to zero, crashing the kernel. An attacker triggers this by sending a crafted RPC request carrying an undersized or header-only sealed token to an NFS server (knfsd) that exports filesystems with RPCSEC_GSS krb5i/krb5p security. Practical impact is primarily remote denial of service of the NFS server, with some out-of-bounds kernel memory reads; the assigned CVSS is 9.8 (critical). No public proof of concept exists and there is no evidence of exploitation in the wild.
What to do: Apply kernel updates from your distribution as soon as patched packages are available, since the fix is a one-line minimum-length check in svcauth_gss. Audit whether any NFS exports use sec=krb5i or sec=krb5p (check /etc/exports and 'exportfs -v') — servers using only sec=sys or sec=krb5 with integrity-only unwrap paths are less exposed. Until patched, firewall port 2049 so only trusted client networks can reach NFS services, and watch NFS server logs/kernels for oopses or panics in svcauth_gss/gss_krb5 code as an indicator of probing.
| Linux kernel (SUNRPC/svcauth_gss, gss_krb5 unwrap) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: svcauth_gss: enforce krb5 token minimum length svcauth_gss_unwrap_priv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gss_unwrap(): if (len > xdr_stream_remaining(xdr)) goto unwrap_failed; offset = xdr_stream_pos(xdr); ... maj_stat = gss_unwrap(ctx, offset, offset + len, buf); The wire value `len` flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gss_unwrap(). For a krb5 v2 context that lands in gss_krb5_unwrap_v2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotate_left() before any integrity check. With a sub-header length the header reads run past the token, and _rotate_left()'s `shift %= buf->len` path can divide by zero when buf->len has been driven to zero by the truncated token. A header-only token (len == 16) is equally invalid: with a non-zero RRC field and the opaque blob ending at the XDR buffer boundary, rotate_left() builds a zero-length subbuffer, reaching the same division. Reject the token at the server entry point before it reaches the krb5 unwrap core. A valid sealed RFC 4121 token must contain the 16-byte header plus at least some encrypted payload. Fix by adding a minimum-length check immediately after the existing upper-bound check: if (len <= GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed;
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.