GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel SUNRPC: integer overflow in krb5p reply length check lets a hostile NFS server drive OOB reads

UnscoredCVE-2026-89541Kernel, userspace & hypervisorcurated

Impact

The bound check on the RPCSEC_GSS opaque length was computed in u32, so a reply declaring a length near 0xffffffff wraps to a small value and passes, and there was no lower bound at all. gss_unwrap() is then called with end below begin, or with a token shorter than the 16-byte krb5 header, driving out-of-bounds reads in gss_krb5_unwrap_v2() and the rotate_left() loop that follows. This is the strongest of the batch: a crafted reply from the fileserver a GPU node mounts reaches host-kernel memory corruption or a panic, taking down whatever training or inference work is resident on that node.

Who can reach it

A krb5p NFS server the node mounts, or anyone able to answer as it on the storage network. The client accepts the malformed reply as part of normal traffic - no extra authentication step is needed beyond the mount already existing.

What to do

Update to a stable kernel carrying the three replacement guards in gss_unwrap_resp_priv() (commits in the record). Until then the only mitigation is to keep krb5p mounts pointed at trusted servers on a trusted network. The kernel update requires draining and rebooting every affected node.

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.