CVE-2026-63801

In the Linux kernel, the following vulnerability has been resolved:

tipc: fix slab-use-after-free Read in tipcaeaddecrypt_done

tipcaeaddecrypt() goes straight from tipcbearerhold(b) to cryptoaeaddecrypt(req) without taking a reference on the netns, unlike the encrypt path. When cryptoaeaddecrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipcaeaddecryptdone() later. If the bearer's netns is torn down in the meantime, cleanupnet() -> tipcexitnet() -> tipccryptostop() frees the per-netns tipccrypto, and the completion then reads it: tipcaeaddecryptdone() dereferences aead->crypto->stats and aead->crypto->net, and tipccryptorcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory.

Decoded KASAN splat (v7.1-rc7, CONFIGKASANINLINE + TIPC + TIPC_CRYPTO):

BUG: KASAN: slab-use-after-free in tipcaeaddecryptdone (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: eventsunbound Call Trace: tipcaeaddecryptdone (net/tipc/crypto.c:999) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

Allocated by task 169: __kasankmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipccryptostart (net/tipc/crypto.c:1502) tipcinitnet (net/tipc/core.c:72) opsinit (net/core/netnamespace.c:137) setupnet (net/core/netnamespace.c:446) copynetns (net/core/netnamespace.c:579) createnewnamespaces (kernel/nsproxy.c:132) __x64sysunshare (kernel/fork.c:3316) dosyscall64 (arch/x86/entry/syscall64.c:63) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)

Freed by task 8: kfree (mm/slub.c:6566) tipcexitnet (net/tipc/core.c:119) cleanupnet (net/core/netnamespace.c:704) processonework (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 tipcaeadencryptdone") fixed for the encrypt side. The encrypt path takes maybegetnet(aead->crypto->net) before cryptoaeadencrypt() and drops it with putnet() on the synchronous return paths and in tipcaeadencrypt_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 cryptoaeaddecrypt() (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 putnet() on the synchronous success/error return and at the end of tipcaeaddecryptdone().

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 tipccryptostop(); 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 tipcaeaddecryptdone() is the unpatched upstream path; tipcaeaddecrypt() still lacks maybegetnet(aead->crypto->net), so the completion can outlive the free on any config where cryptoaead_decrypt() goes async.

Found by 0sec automated security-research tooling (https://0sec.ai).