CVE-2026-63801

Status: UPDATED  |  Advisory ID: CVE-2026-63801

Key Details

Affected Products, Subsystems & Sectors

What to Know

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

What to Do

Monitor Linux's web page for any future patch releases.

References