CVE-2026-63801: Linux Kernel Use-After-Free Vulnerability

CVE-2026-63801 Overview

CVE-2026-63801 is a slab use-after-free vulnerability in the Linux kernel's Transparent Inter-Process Communication (TIPC) subsystem. The flaw resides in the tipc_aead_decrypt() function within net/tipc/crypto.c. When decryption is offloaded asynchronously through the SIMD AEAD wrapper or cryptd, the completion handler tipc_aead_decrypt_done() can outlive the network namespace teardown. If tipc_exit_net() frees the per-netns tipc_crypto structure before the async callback runs, the completion reads freed memory including aead->crypto->stats, aead->crypto->net, and aead->crypto->aead[].

Critical Impact
A local attacker with network access to a TIPC bearer using cluster keys can trigger memory corruption in kernel space, potentially leading to privilege escalation or denial of service.

Affected Products

Linux kernel versions containing the TIPC crypto subsystem with CONFIG_TIPC and CONFIG_TIPC_CRYPTO enabled
Confirmed reproducible on Linux kernel v7.1-rc7 under KASAN
Systems where crypto_aead_decrypt() operates asynchronously (e.g., via cryptd offload)

Discovery Timeline

2026-07-19 - CVE-2026-63801 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-63801

Vulnerability Analysis

The vulnerability stems from an asymmetry between the TIPC encrypt and decrypt code paths. The encrypt path calls maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() to hold a reference on the network namespace across asynchronous completions. The decrypt path proceeds directly from tipc_bearer_hold(b) to crypto_aead_decrypt() without acquiring the equivalent netns reference.

When crypto_aead_decrypt() returns -EINPROGRESS or -EBUSY, the actual decryption completes later in a cryptd worker thread. If cleanup_net() invokes tipc_exit_net() and tipc_crypto_stop() in the interim, the per-netns tipc_crypto structure is freed via kfree(). The scheduled tipc_aead_decrypt_done() callback then dereferences the freed structure, producing the KASAN slab-use-after-free splat documented at address ffff8881056258a8.

Root Cause

The root cause is a missing reference count on the network namespace during asynchronous AEAD decryption. Commit e279024617134 previously fixed the identical bug class on the encrypt side via maybe_get_net() and put_net(), but the decrypt path was left unguarded. Any kernel configuration where crypto_aead_decrypt() completes asynchronously exposes this race window.

Attack Vector

The reproduction scenario involves a UDP bearer configured with a TIPC cluster key. An attacker floods the bearer with crafted encrypted frames from an unknown peer, driving the cluster-key decrypt path. Concurrently, the bearer's network namespace is repeatedly torn down. On x86 systems where AES-NI provides synchronous gcm(aes), the async path can be forced through cryptd offload. The completion executes after tipc_crypto_stop() frees the target memory, triggering the use-after-free read.

See the kernel patch dca7713f and related fixes for the exact code delta that mirrors the encrypt-side guard.

Detection Methods for CVE-2026-63801

Indicators of Compromise

KASAN reports referencing tipc_aead_decrypt_done at net/tipc/crypto.c:999 with slab-use-after-free Read classification
Kernel panics or oopses originating from events_unbound workqueue calling into TIPC crypto completion handlers
Unexplained TIPC bearer teardown activity coinciding with encrypted TIPC frame traffic from unknown peers

Detection Strategies

Enable CONFIG_KASAN_INLINE in test and staging kernels to surface use-after-free reads in tipc_aead_decrypt_done() during pre-production validation
Monitor kernel ring buffer via dmesg for BUG: KASAN entries referencing net/tipc/crypto.c
Audit hosts for enabled CONFIG_TIPC and CONFIG_TIPC_CRYPTO combined with active TIPC bearers, which represents the exploitable surface

Monitoring Recommendations

Track network namespace creation and teardown rates via unshare() and cleanup_net() telemetry for anomalous churn
Alert on unexpected TIPC bearer configuration changes, particularly cluster key installation on UDP bearers
Correlate kernel crash signatures with inbound encrypted TIPC traffic from unauthorized source addresses

How to Mitigate CVE-2026-63801

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the NVD advisory to the running kernel and reboot affected hosts
Disable the TIPC module (modprobe -r tipc) on systems that do not require TIPC functionality
Restrict TIPC bearer configuration to trusted administrators via kernel capability controls

Patch Information

The upstream fix mirrors the encrypt-side remediation by acquiring a netns reference before crypto_aead_decrypt() and releasing it appropriately on synchronous returns, error paths, and inside tipc_aead_decrypt_done() for the async case. Fix commits include 0a780653, 171d3124, 1eea5e18, 2d1f2141, bda33488, dca7713f, e1876961, and eaca7dae.

Workarounds

Blacklist the tipc kernel module on hosts that do not use inter-process cluster communication
Avoid enabling TIPC cluster keys on UDP bearers exposed to untrusted networks until patches are applied
Where feasible, prefer kernel configurations where crypto_aead_decrypt() completes synchronously to shrink the race window, understanding this is mitigation and not remediation

bash

# Configuration example: disable TIPC module loading
echo "blacklist tipc" | sudo tee /etc/modprobe.d/blacklist-tipc.conf
sudo rmmod tipc 2>/dev/null || true
sudo update-initramfs -u