GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel nfsd: undersized Kerberos token reaches the krb5 unwrap core and divides by zero

UnscoredCVE-2026-89550Kernel, userspace & hypervisorcurated

Impact

svcauth_gss_unwrap_priv() checked only an upper bound on the wire-supplied opaque length, so a length of 0 to 16 bytes was handed straight to gss_unwrap(). gss_krb5_unwrap_v2() then reads the 16-byte RFC 4121 header fields and calls rotate_left() before any integrity check, so a truncated token makes the header reads run past the buffer and _rotate_left()'s shift %= buf->len divide by zero. A header-only 16-byte token with a non-zero RRC reaches the same division. This is the server-side krb5p path of an NFS server: a malformed packet takes down the kernel before authentication succeeds. On a cluster where a kerberised NFS server backs the training data for many nodes, one crafted RPC stalls every job reading from that server.

Who can reach it

Remote, over the network, from anyone who can open an RPC connection to a kernel NFS server configured with krb5 security. The malformed token is rejected before the integrity check, so a valid Kerberos credential is not needed to reach the faulting code.

What to do

Patch to a stable kernel carrying the minimum-length check (len <= GSS_KRB5_TOK_HDR_LEN is now rejected at the server entry point) and reboot the NFS server nodes. Until then, restrict which networks can reach port 2049 on kerberised exports; disabling krb5 security removes the path but is a security downgrade. The record lists the stable commits and no fixed version numbers.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.