CVE-2026-63801

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done<br /> <br /> tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to<br /> crypto_aead_decrypt(req) without taking a reference on the netns, unlike<br /> the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously<br /> (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs<br /> tipc_aead_decrypt_done() later. If the bearer&amp;#39;s netns is torn down in the<br /> meantime, cleanup_net() -&gt; tipc_exit_net() -&gt; tipc_crypto_stop() frees the<br /> per-netns tipc_crypto, and the completion then reads it:<br /> tipc_aead_decrypt_done() dereferences aead-&gt;crypto-&gt;stats and<br /> aead-&gt;crypto-&gt;net, and tipc_crypto_rcv_complete() dereferences<br /> aead-&gt;crypto-&gt;aead[] and the node table -- reading freed memory.<br /> <br /> Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO):<br /> <br /> BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999)<br /> Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51<br /> Workqueue: events_unbound<br /> Call Trace:<br /> tipc_aead_decrypt_done (net/tipc/crypto.c:999)<br /> process_one_work (kernel/workqueue.c:3314)<br /> worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)<br /> kthread (kernel/kthread.c:436)<br /> ret_from_fork (arch/x86/kernel/process.c:158)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)<br /> <br /> Allocated by task 169:<br /> __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)<br /> tipc_crypto_start (net/tipc/crypto.c:1502)<br /> tipc_init_net (net/tipc/core.c:72)<br /> ops_init (net/core/net_namespace.c:137)<br /> setup_net (net/core/net_namespace.c:446)<br /> copy_net_ns (net/core/net_namespace.c:579)<br /> create_new_namespaces (kernel/nsproxy.c:132)<br /> __x64_sys_unshare (kernel/fork.c:3316)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> <br /> Freed by task 8:<br /> kfree (mm/slub.c:6566)<br /> tipc_exit_net (net/tipc/core.c:119)<br /> cleanup_net (net/core/net_namespace.c:704)<br /> process_one_work (kernel/workqueue.c:3314)<br /> kthread (kernel/kthread.c:436)<br /> <br /> This is the same class of bug that commit e279024617134 ("net/tipc: fix<br /> slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt<br /> side. The encrypt path takes maybe_get_net(aead-&gt;crypto-&gt;net) before<br /> crypto_aead_encrypt() and drops it with put_net() on the synchronous<br /> return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY<br /> return keeps the reference for the async callback to release. The decrypt<br /> path was left without the equivalent guard.<br /> <br /> Mirror the encrypt-side fix on the decrypt path: take a net reference<br /> before crypto_aead_decrypt() (failing with -ENODEV and the matching<br /> bearer put if it cannot be acquired), keep it across the<br /> -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the<br /> synchronous success/error return and at the end of<br /> tipc_aead_decrypt_done().<br /> <br /> Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is<br /> flooded with crafted encrypted frames from an unknown peer (driving the<br /> cluster-key decrypt path) while the bearer&amp;#39;s netns is repeatedly torn<br /> down. The completion must run asynchronously to outlive<br /> tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts<br /> synchronously, so the async path was exercised via cryptd offload. The<br /> unguarded aead-&gt;crypto dereference in tipc_aead_decrypt_done() is the<br /> unpatched upstream path; tipc_aead_decrypt() still lacks<br /> maybe_get_net(aead-&gt;crypto-&gt;net), so the completion can outlive the free<br /> on any config where crypto_aead_decrypt() goes async.<br /> <br /> Found by 0sec automated security-research tooling (https://0sec.ai).