CVE-2026-63801

What it actually does

This is a Linux kernel use-after-free in the TIPC encrypted receive path. When TIPC AEAD decryption is completed asynchronously, the decrypt callback can run after the associated network namespace has been destroyed and its per-namespace TIPC crypto structures have been freed. The callback then dereferences freed kernel memory, including TIPC crypto statistics, namespace pointers, AEAD state, and node-table data. Depending on kernel configuration, allocator state, and exploitability conditions, this can result in kernel memory disclosure, corruption, privilege escalation, or denial of service through a kernel crash.

Why it matters to the business

Systems that enable TIPC, especially encrypted TIPC over UDP bearers, may be exposed to a high-impact kernel memory corruption flaw. A successful attack could crash affected Linux hosts or potentially allow deeper compromise of the operating system. The issue is not currently listed in CISA KEV, has no reported mature public exploit, and has a low EPSS score, but the CVSS impact is high because exploitation affects the kernel and can compromise confidentiality, integrity, and availability. Organizations using containers, network namespaces, or workloads that grant namespace or network-administration capabilities should treat exposure as more urgent.

How an attack unfolds

An attacker needs conditions where TIPC is enabled and encrypted TIPC traffic is processed through an asynchronous AEAD decrypt path. In the demonstrated scenario, crafted encrypted TIPC frames are sent to a UDP bearer while the relevant network namespace is being torn down. Because the decrypt path does not hold a reference to the network namespace before submitting the asynchronous crypto operation, namespace cleanup can free the per-namespace TIPC crypto object before the crypto completion handler runs. When the delayed completion callback executes, it reads fields through the stale TIPC crypto pointer. This can trigger a kernel use-after-free, typically seen as a KASAN splat or kernel oops, and may be exploitable for broader kernel memory corruption depending on timing and heap layout. The practical attack surface is limited to systems where TIPC is loaded/configured and where an attacker can either influence TIPC encrypted traffic and namespace lifecycle or operate with sufficient local privileges such as CAP_NET_ADMIN or equivalent container escape-adjacent capabilities.

How to fix it

Apply a vendor-supported Linux kernel update that includes the upstream fix for the TIPC decrypt path reference-counting bug in net/tipc/crypto.c. Because exact fixed package versions were not provided, track the relevant distribution kernel advisories and confirm the patch description includes language similar to "tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done" or an equivalent TIPC AEAD decrypt namespace reference fix. If immediate patching is not possible, reduce exposure by disabling TIPC where it is not required, unloading or blacklisting the tipc module, removing unused TIPC bearers, blocking TIPC UDP bearer traffic at host and network firewalls, and restricting CAP_NET_ADMIN, unprivileged user namespaces, and container configurations that allow users to create or destroy network namespaces. These mitigations reduce reachable attack surface but should not be treated as substitutes for a kernel update.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and package changelog against the operating-system vendor advisory for this issue. Check whether TIPC is loaded or configured using module inventory and TIPC tooling, such as reviewing lsmod output for tipc, checking /sys/module/tipc, and inspecting TIPC bearer configuration. Where feasible in a non-production test environment, validate that encrypted TIPC traffic and namespace teardown no longer produce KASAN, kernel oops, or panic messages referencing tipc_aead_decrypt_done. After patching, reboot into the fixed kernel and confirm no vulnerable kernel remains active through uname -r and package-manager queries.

Typical attack path

1. Identify a Linux host or container environment where the TIPC kernel module/protocol is enabled.
2. Determine whether TIPC bearers, especially UDP bearers with cluster-key encryption, are configured and reachable.
3. Obtain the ability to send crafted TIPC encrypted frames to the bearer or operate from a context that can interact with TIPC networking.
4. Create timing pressure by causing asynchronous AEAD decrypt operations while the relevant network namespace is destroyed or recycled.
5. Trigger the delayed decrypt completion after TIPC crypto state has been freed.
6. Abuse the resulting kernel use-after-free to cause a crash or attempt kernel memory corruption for privilege escalation.

How to detect it

Successful exploitation of kernel use-after-free vulnerabilities may leave few application-level indicators, so detection should focus on kernel telemetry, crash artifacts, module/configuration state, and suspicious namespace or TIPC activity. Review kernel logs from journalctl, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, and kdump/vmcore records for KASAN reports, slab-use-after-free messages, kernel oopses, panics, or workqueue crashes involving TIPC crypto functions. Look for TIPC being unexpectedly loaded or configured, new or unusual TIPC bearers, and network traffic to configured TIPC UDP bearer ports from untrusted peers. On container hosts, correlate kernel faults with audit logs or EDR telemetry showing repeated unshare, clone, setns, ip netns, or namespace teardown activity by untrusted users or containers. If kernel crash dumps are available, inspect stack traces for tipc_aead_decrypt_done and freed TIPC crypto structures. Absence of these artifacts does not prove non-exploitation, because a successful privilege-escalation attempt may avoid a crash or clear logs after gaining control.

• BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done
• slab-use-after-free in tipc_aead_decrypt_done
• tipc_aead_decrypt_done
• tipc_crypto_rcv_complete
• tipc_crypto_stop
• tipc_exit_net
• cleanup_net
• Workqueue: events_unbound
• crypto_aead_decrypt
• net/tipc/crypto.c
• net/tipc/core.c
• /sys/module/tipc
• /proc/net/tipc
• tipc bearer
• tipc node
• tipc link
• UDP/6118
• unshare(CLONE_NEWNET)
• CLONE_NEWNET
• CAP_NET_ADMIN
• kworker
• KASAN: use-after-free
• kernel BUG at net/tipc/crypto.c
• Oops:
• Kernel panic

What your security team should do

• Inventory Linux systems for TIPC usage and prioritize hosts where the tipc module is loaded, TIPC bearers are configured, or container workloads have CAP_NET_ADMIN or network namespace creation privileges.
• Patch affected Linux kernels as soon as vendor-fixed packages are available, prioritizing externally reachable, multi-tenant, container-hosting, and high-availability systems.
• Disable or blacklist TIPC on systems that do not explicitly require it.
• Restrict unprivileged user namespaces and remove unnecessary CAP_NET_ADMIN privileges from containers and services.
• Block or tightly restrict TIPC bearer traffic, including UDP-based TIPC bearers, to trusted cluster peers only.
• Monitor kernel logs for crashes, KASAN reports, workqueue crashes, or oops traces involving tipc_aead_decrypt_done, tipc_crypto_rcv_complete, tipc_exit_net, or cleanup_net.
• Review container runtime and orchestration policies for workloads capable of repeatedly creating and destroying network namespaces.
• Because public exploit maturity is currently listed as none and EPSS is low, balance urgency with exposure: patch all affected systems, but escalate immediately where TIPC is enabled or reachable.