Linux kernel krb5 crypto: use-after-free when an async AEAD backend is bound to the enctype

Impact

The in-kernel krb5 encrypt/decrypt helpers were written for synchronous AEAD only: they install a NULL completion callback and treat any negative return as terminal, so an -EINPROGRESS from an async AEAD instance causes the buffer to be freed while the backend worker still holds a pointer to it. The worker then writes into freed slab memory. The consumers named in the commit are net/rxrpc, fs/afs and net/ceph/crypto.c, and the Ceph messenger path is the one that matters on a GPU fleet: Ceph is a common backing store for training data and checkpoints, so the vulnerable code runs on storage clients across the cluster, not on one box. The fix filters async instances out at allocation time. Reachability is conditional: an async AEAD provider (typically a hardware crypto offload driver) must be bound to the algorithm name for the krb5 enctype in use, which is not the default on most builds.

Who can reach it

Requires the node to be doing kerberised rxrpc/AFS or Ceph traffic with an async AEAD implementation registered for the enctype. In that configuration the trigger is remote traffic on those protocols; the kernel CNA scored it AV:N/PR:N. On a stock configuration with only synchronous AEAD implementations available, the path is not reached.

What to do

Take a stable kernel carrying the three fix commits listed in the record and reboot each node - the record names commits, not release numbers, so check your distro's advisory for the version that contains them. There is no runtime mitigation short of avoiding an async AEAD provider for the krb5 enctype. On GPU nodes this is a drain-and-reboot per host; on a Ceph client fleet it is every node, so it is normal maintenance-window work rather than an emergency unless you actually run kerberised Ceph or AFS with crypto offload.

References

Related entries

• Linux kernel (drivers/nvme/target): A client connected to your NVMe-oF TCP target can drive a reference-count underflowCVE-2026-64534 · Linux kernel (drivers/nvme/target)Critical
• Linux kernel NVMe-oF TCP target (nvmet-tcp, data-digest mismatch handling): With data digests enabled, a digestCVE-2026-64535 · Linux kernel NVMe-oF TCP target (nvmet-tcp, data-digest mismatch handling)Critical
• Linux kernel SMC-R connection data control (smc_cdc_rx_handler socket lifetime): The CDC receive handler looks theCVE-2026-64541 · Linux kernel SMC-R connection data control (smc_cdc_rx_handler socket lifetime)Critical
• Linux kernel (net/xfrm): The same ownership-marker bug as CVE-2026-53363, in the other IPTFS frag-transfer helper.CVE-2026-64566 · Linux kernel (net/xfrm)Critical
• Linux kernel libceph: malicious OSD triggers out-of-bounds reads in RBD lock-info decodeCVE-2026-68082 · Linux kernel libceph (decode_lockers() in cls_lock_client.c)Critical
• Linux libceph: CRUSH map with a zero bucket type makes the mapper index the OSD weight array negativelyCVE-2026-68154 · Linux kernel libceph (crush_decode, CRUSH map bucket type validation)Critical