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

CVE-2026-68117 Overview

CVE-2026-68117 is a use-after-free vulnerability in the Linux kernel's Transparent Inter-Process Communication (TIPC) socket implementation. The flaw resides in tipc_sk_create(), which frees the socket structure on the failed-insert path but leaves sock->sk pointing at the freed object. When triggered via the accept() code path, tipc_release() executes lock_sock() on the freed sk, producing a use-after-free write on the sk_lock spinlock. KASAN reports confirm the slab-use-after-free in lock_sock_nested(). The condition is reached once the per-netns TIPC socket rhashtable reaches its max_size of 1,048,576 entries, causing every subsequent insert to return -E2BIG.

Critical Impact
Local attackers able to exhaust the TIPC socket table can trigger a kernel use-after-free write, enabling denial of service and potential local privilege escalation.

Affected Products

Linux kernel builds with CONFIG_TIPC enabled, prior to the commits listed under Patch Information
Distributions shipping vulnerable stable/longterm kernel branches
Containerized and multi-tenant hosts exposing per-netns TIPC socket creation to unprivileged users

Discovery Timeline

2026-08-10 - CVE-2026-68117 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68117

Vulnerability Analysis

The TIPC subsystem allocates a new socket via sk_alloc() and then calls tipc_sk_insert() to register it in the per-namespace rhashtable. When tipc_sk_insert() fails, the error path calls sk_free(sk) and returns -EINVAL, but does not clear sock->sk. This behavior is benign for a plain socket() syscall because the syscall layer clears sock->ops before releasing, so tipc_release() is not invoked.

The accept path behaves differently. tipc_accept() invokes tipc_sk_create(net, new_sock, 0, kern) on a pre-allocated child socket. On failure, new_sock->sk is left dangling and new_sock->ops remains non-NULL. do_accept() then calls fput() on the new file, driving __sock_release() into tipc_release(). That handler executes lock_sock(new_sock->sk) on the freed sk, corrupting the sk_lock spinlock. This is [CWE-416] Use After Free.

Root Cause

The root cause is asymmetric error handling in tipc_sk_create(). tipc_release() already contains a guard for the failed-accept case with if (sk == NULL) return 0;, but the guard is bypassed because the failed-insert path leaves sock->sk non-NULL and dangling instead of NULL.

Attack Vector

Exploitation requires the per-netns TIPC socket rhashtable to reach its 1,048,576 element ceiling. Once that limit is reached, every subsequent tipc_sk_insert() returns -E2BIG. An accept() call on a listening TIPC socket then walks the vulnerable error path and produces the use-after-free write. In multi-tenant environments and containers where users can create user namespaces and network namespaces, an unprivileged local actor can drive the socket table to exhaustion and race the accept path.

Exploitation code is not being published; see the upstream commits referenced under Patch Information for the corrective code path.

Detection Methods for CVE-2026-68117

Indicators of Compromise

Kernel log entries containing Socket create failed; port number exhausted originating from pr_warn() in tipc_sk_create()
KASAN reports of slab-use-after-free in lock_sock_nested with a call stack including tipc_release, __sock_release, and sock_close
Sudden kernel panics or oopses in lock_sock_nested() on hosts with TIPC enabled

Detection Strategies

Monitor for processes creating large numbers of TIPC sockets within a single network namespace, approaching the 1,048,576 element rhashtable limit
Alert on repeated EINVAL returns from TIPC socket syscalls followed by accept() failures on the same descriptor
Track loading of the tipc.ko module on hosts where TIPC is not required, and flag the event for review

Monitoring Recommendations

Ingest /var/log/kern.log, dmesg, and journald output into centralized logging and search for TIPC warning strings and KASAN signatures
Instrument accept() failure rates on TIPC-enabled workloads and correlate with process-level socket creation counts
Baseline TIPC usage per namespace so anomalous growth in socket count triggers investigation

How to Mitigate CVE-2026-68117

Immediate Actions Required

Apply the upstream stable kernel updates that clear sock->sk on the failed-insert path in tipc_sk_create()
If TIPC is not required for workloads, blacklist the tipc kernel module and prevent autoload
Audit container and namespace policies to restrict unprivileged creation of TIPC sockets

Patch Information

The fix clears sock->sk = NULL on the failed-insert path so the existing tipc_release() NULL check fires. Corrective commits are available upstream: Kernel Git Commit 5f5a41a, Kernel Git Commit b07d87b, Kernel Git Commit ba0533f, Kernel Git Commit dd2989a, and Kernel Git Commit f9596b1.

Workarounds

Disable and blacklist the tipc module on systems that do not require Transparent Inter-Process Communication
Restrict unprivileged user namespace creation to prevent attackers from constructing isolated netns that host their own TIPC socket table
Apply resource controls (cgroups, ulimits) to cap the number of sockets a single process or container can create

bash

# Disable the TIPC module on hosts that do not require it
echo 'install tipc /bin/true' | sudo tee /etc/modprobe.d/disable-tipc.conf
sudo rmmod tipc 2>/dev/null || true

# Restrict unprivileged user namespace creation
sudo sysctl -w kernel.unprivileged_userns_clone=0