CVE-2026-89541

The Linux kernel's SUNRPC/RPCSEC_GSS client code computes the reply bound check 'offset + opaque_len' entirely in 32-bit unsigned arithmetic, so a malicious reply declaring an opaque length near 0xffffffff wraps the sum to a small value, defeats the check, and passes an out-of-range end pointer into gss_unwrap(), reading kernel memory beyond the receive buffer. The flaw is triggered when a client with an active RPCSEC_GSS (e.g., NFS mounted with krb5i/krb5p) receives a crafted reply, which in practice requires an attacker to control, compromise, or spoof the RPC/NFS server the client is talking to. Because the malformed length is processed during unwrap handling, an attacker could gain out-of-bounds read of kernel memory (information disclosure) or crash the client (denial of service); CVSS 3.1 is rated 9.8 critical. The fix rewrites the checks into overflow-safe form — first rejecting offset > rcv_buf->len, then comparing opaque_len against rcv_buf->len - offset, and enforcing a minimum GSS_KRB5 token length floor mirroring the server-side check from commit 5b757c2e57a5. No public proof of concept or in-the-wild exploitation is known.

What to do: Apply distribution kernel updates that backport the hardened gss_unwrap_resp_priv() checks (look for the SUNRPC unwrap hardening commit in your vendor's changelog). Until patched, avoid krb5i/krb5p mounts against untrusted or internet-facing NFS servers and constrain clients to known servers via fixed addresses and Kerberos realm policy. Monitor NFS clients for kernel oops or crashes originating in net/sunrpc/auth_gss during reply processing.