CVE-2026-64439 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: krb5 - filter out async aead implementations at alloc
krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL completion callback and treat any negative return from crypto_aead_{encrypt,decrypt}() as terminal, falling through to
kfree_sensitive(buffer). When the encrypt_name resolves to an async AEAD instance the request returns -EINPROGRESS, the buffer is freed while the backend's worker still holds a pointer, and the worker dereferences the freed slab on completion.
KASAN report under UML+SLUB with a synthetic async aead backend bound to krb5->encrypt_name:
BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7
The helpers were written synchronously, so filter the async instances out at allocation time instead of plumbing crypto_wait_req() through every call site.
Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and net/ceph/crypto.c on systems with an async AEAD provider bound to the krb5 enctype name.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability exists within the Linux kernel's cryptographic subsystem, specifically affecting the Kerberos 5 (krb5) implementation in the crypto framework. The flaw stems from improper handling of asynchronous AEAD (Authenticated Encryption with Associated Data) implementations during encryption and decryption operations. The krb5_aead_encrypt() and krb5_aead_decrypt() functions in rfc3961_simplified.c, along with rfc8009_encrypt() and rfc8009_decrypt() in rfc8009_aes2.c, were designed with synchronous operation assumptions but fail to account for asynchronous implementations that may be registered under the same encryption type names. When an async AEAD provider is bound to a krb5 enctype name, these functions encounter negative return codes including -EINPROGRESS from crypto_aead_{encrypt,decrypt}() operations and proceed to free memory without proper synchronization.
The technical execution of this vulnerability occurs when the system resolves an encrypt_name to an asynchronous AEAD instance. The code sets a NULL completion callback and treats any negative return value as terminal, causing immediate memory deallocation through kfree_sensitive(buffer) before asynchronous processing completes. This creates a classic use-after-free scenario where the kernel backend's worker thread continues processing and attempts to dereference a slab that has already been freed, resulting in memory corruption. The KASAN report demonstrates this through a slab-use-after-free error in t5_stub_complete function, indicating that the freed memory is accessed during asynchronous completion processing.
The operational impact of this vulnerability extends across multiple kernel subsystems that utilize krb5 encryption, specifically net/rxrpc/rxgk.c for remote execution protocol security, fs/afs/cm_security.c for Andrew File System security, and net/ceph/crypto.c for Ceph storage cluster cryptography. Systems with asynchronous AEAD providers registered under krb5 enctype names become vulnerable to memory corruption attacks that could potentially lead to privilege escalation or system instability. This vulnerability directly relates to CWE-416: Use After Free and CWE-129: Improper Validation of Array Index, as it involves both improper memory management and inadequate validation of asynchronous operation results. The attack surface is particularly concerning because it affects core security protocols used in distributed computing environments where Kerberos authentication is prevalent.
The mitigation strategy for this vulnerability focuses on filtering out asynchronous AEAD implementations at allocation time rather than attempting to handle asynchronous operations throughout the call stack. This approach aligns with the principle of defensive programming and prevents the problematic scenario from occurring in the first place. The solution involves modifying the kernel's crypto framework to ensure that only synchronous AEAD implementations are selected for krb5 operations, eliminating the race condition between memory deallocation and asynchronous completion processing. This fix directly addresses the root cause rather than attempting to retrofit asynchronous handling throughout the existing codebase, which would be more complex and error-prone. The implementation should be consistent with ATT&CK technique T1068: Exploitation for Privilege Escalation by preventing the exploitation vector that leads to memory corruption in kernel space.
The vulnerability demonstrates a fundamental mismatch between synchronous and asynchronous cryptographic operation models within the Linux kernel's crypto framework. This type of issue commonly occurs when legacy code assumptions about operation characteristics are not properly validated against modern implementation patterns, particularly in security-critical subsystems where memory safety is paramount. The fix represents a proper architectural approach to handling this class of problem by ensuring that the crypto framework's selection logic accounts for operation characteristics at the appropriate layer, preventing asynchronous operations from being inadvertently selected for synchronous code paths that do not properly handle them. This vulnerability highlights the importance of considering all possible implementations when designing security-critical cryptographic interfaces and underscores the need for comprehensive testing across different backend provider configurations to prevent similar issues in other kernel subsystems.