CVE-2026-63801 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done
tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory.
Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO):
BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436)
This is the same class of bug that commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard.
Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done().
Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async.
Found by 0sec automated security-research tooling (https://0sec.ai).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability described represents a use-after-free condition in the Linux kernel's TIPC (Transparent Inter-Process Communication) subsystem, specifically within the cryptographic component responsible for AEAD (Authenticated Encryption with Associated Data) decryption operations. This flaw occurs due to an asymmetric handling of network namespace references between the encryption and decryption paths, creating a race condition that allows memory to be accessed after it has been freed. The issue manifests in the tipc_aead_decrypt_done() function which is invoked asynchronously by the cryptd worker thread, long after the original bearer's network namespace may have been torn down during cleanup operations.
The technical root cause stems from the fact that while the encryption path properly implements reference counting through maybe_get_net() before invoking crypto_aead_encrypt(), the decryption path omits this crucial safeguard. When crypto_aead_decrypt() is offloaded asynchronously—such as through the SIMD aead wrapper queuing to cryptd—the completion handler tipc_aead_decrypt_done() executes later in a different context, potentially after the network namespace has already been freed by cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop(). This sequence leaves the decryption completion callback accessing freed memory structures including aead->crypto->stats, aead->crypto->net, and various node table entries, resulting in a slab-use-after-free condition.
This vulnerability aligns with CWE-416: Use After Free, which is categorized under the broader class of memory safety issues in software development. The flaw demonstrates a classic race condition pattern where resources are not properly protected across asynchronous operation boundaries, particularly in kernel networking subsystems where workqueue callbacks and delayed execution contexts are common. The issue also maps to ATT&CK technique T1059.008: Command and Scripting Interpreter: PowerShell, though more directly relates to privilege escalation through kernel memory corruption that could be leveraged for system compromise.
The operational impact of this vulnerability is significant as it can lead to system instability, potential denial of service conditions, or even arbitrary code execution depending on the attacker's ability to control the timing and nature of the cryptographic operations. The vulnerability requires specific conditions to be exploited: a TIPC UDP bearer with cluster key configuration, active encrypted frame traffic from unknown peers, and concurrent network namespace teardown operations. However, once triggered, it can result in kernel memory corruption that may manifest as system crashes or more subtle security implications.
The fix implemented mirrors the solution previously applied to the encryption path (commit e279024617134) by ensuring that the decryption path also takes a proper network namespace reference before calling crypto_aead_decrypt(). This involves acquiring the reference with maybe_get_net() and maintaining it across asynchronous operations until the completion handler releases it through put_net(). The fix ensures that even if the network namespace is torn down during the async decryption process, the referenced structures remain valid for the duration of the completion callback execution. This approach maintains consistency between the encryption and decryption code paths while preventing the use-after-free condition that could otherwise lead to kernel panic or security exploits in environments utilizing TIPC with cryptographic features.
The vulnerability was discovered through automated security research tooling (0sec), highlighting the importance of systematic analysis of kernel subsystems for race conditions and memory safety issues. The KASAN (Kernel Address Sanitizer) output clearly demonstrates the memory access patterns that lead to the use-after-free condition, showing the allocation in tipc_crypto_start() and subsequent freeing in tipc_exit_net(), with the problematic read occurring in tipc_aead_decrypt_done(). This type of vulnerability underscores the complexity of kernel security and the necessity for comprehensive testing of asynchronous code paths, particularly in network subsystems where operations may span multiple execution contexts and timing windows.