CVE-2026-63801

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).

• CWE-416

• https://git.kernel.org/stable/c/0a780653b2a7569a7af9be7d0b00b1251baca63aPatch
• https://git.kernel.org/stable/c/171d31245d11bf84836fad3b394cb465a4d008ecPatch
• https://git.kernel.org/stable/c/1eea5e1820a2f5164d706bd1277bc97ff31ce32dPatch
• https://git.kernel.org/stable/c/2d1f21419ec121232c916d3a3fc9b6766473a0e7Patch
• https://git.kernel.org/stable/c/bda3348872a2ef0d19f2df6aa8cb5025adce2f20Patch
• https://git.kernel.org/stable/c/dca7713fe044a2067387948557ea099056e1679ePatch
• https://git.kernel.org/stable/c/e18769616fd5a90ec1e12aabbba544c488284292Patch
• https://git.kernel.org/stable/c/eaca7dae02fab70c8d223cffe03cec1b93249ce2Patch

Published

Jul 19, 2026

Last Modified

Jul 29, 2026

Status

Analyzed

• How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
• Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
• PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
• AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.

• CVE-2026-63795In the Linux kernel, the following vulnerability has been re…10
• CVE-2026-63796In the Linux kernel, the following vulnerability has been re…8.8
• CVE-2026-63797In the Linux kernel, the following vulnerability has been re…8.4
• CVE-2026-63798In the Linux kernel, the following vulnerability has been re…5.5
• CVE-2026-63799In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-63800In the Linux kernel, the following vulnerability has been re…9.8
• CVE-2026-63802In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-63803In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-63804In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-63805In the Linux kernel, the following vulnerability has been re…7.8
• CVE-2026-63806In the Linux kernel, the following vulnerability has been re…7.1
• CVE-2026-63807In the Linux kernel, the following vulnerability has been re…8.8