Linux kernel crypto/krb5: derived Kerberos keys left in freed slab memory

Impact

crypto_krb5_prepare_encryption() and crypto_krb5_prepare_checksum() released the buffer holding freshly derived Kerberos keys with plain kfree() instead of kfree_sensitive(), so the key material stays in the freed slab object until that memory is reused. On a GPU node this matters where kerberized NFS (RPCSEC_GSS krb5p/krb5i) is the path to the shared dataset and checkpoint storage: session key material recoverable from reused slab memory undermines the confidentiality of that mount. The record gives no exploit path of its own - recovery requires an attacker who can already read kernel slab contents through some other primitive, so treat this as removing a defence-in-depth failure rather than as a directly reachable bug. The CVSS AV:N vector assigned to the record is not supported by the commit message, which describes only residual key material in freed memory.

Who can reach it

No independent remote path. Requires an attacker who can already read freed kernel slab memory on the host - a local user chaining a separate kernel information-leak, or a compromised kernel context. Nodes that never use kerberized NFS or krb5 RPCSEC_GSS do not reach this code at all.

What to do

Pick up the fix from your distribution's stable kernel (upstream commits linked in the references); it is a one-line change from kfree() to kfree_sensitive() on the derived-key buffers. Applying it means installing a new kernel and rebooting each node, which on a GPU fleet means draining running jobs first. Given the limited exposure, batching this into the next scheduled kernel roll is reasonable rather than opening a window for it alone.

References

Related entries

• Linux kernel ntb_transport: oversized transmit buffers leak skbs until the host runs out of memoryCVE-2026-80987 · Linux kernel NTB ntb_transport / ntb_netdev (oversized TX buffer skb leak)High
• OpenSSL 4.0: use-after-free in the X.509 extension cache crashes multi-threaded TLS peersCVE-2026-84783 · OpenSSL 4.0 X.509 extension cache (concurrent X509 use)High
• OpenSSL QUIC: unthrottled RETIRE_CONNECTION_ID backlog lets a peer force ~400MB of allocationCVE-2026-84784 · OpenSSL QUIC stack (NEW_CONNECTION_ID / RETIRE_CONNECTION_ID handling)High
• Linux kernel SUNRPC: gssx decode error paths NULL-deref and leak group_info on the NFS serverCVE-2026-89544 · Linux kernel nfsd/SUNRPC gssx option-array decoder (gss-proxy upcall)High
• Linux kernel nfsd: transports routed to threadless service pools hang the connection indefinitelyCVE-2026-89549 · Linux kernel SUNRPC svc_pool_for_cpu() (nfsd pool-to-CPU routing)High
• Linux kernel nfsd: broken short-write detection writes the next segment at the wrong file offsetCVE-2026-89678 · Linux kernel nfsd_direct_write() (NFS server direct-I/O write path)High