CVE-2026-68117

What it actually does

This is a Linux kernel use-after-free in the TIPC socket creation error path. When TIPC socket insertion fails because the per-network-namespace TIPC socket hash table has reached its maximum size, the kernel frees the newly allocated socket state but leaves the parent socket structure pointing to the freed object. On the accept() path, that dangling pointer can later be passed into tipc_release(), which attempts to lock the already-freed socket and performs a write to freed kernel memory. The most likely practical impact is a kernel crash or denial of service; depending on allocator state, kernel configuration, and exploit reliability, use-after-free conditions can sometimes become local privilege-escalation primitives, but this flaw requires unusual socket-count exhaustion conditions and has no known public exploitation as of the provided data.

Why it matters to the business

Systems using Linux kernel TIPC could be made unstable if an attacker or untrusted workload can create very large numbers of TIPC sockets in a network namespace and trigger the failed accept() path. The operational risk is primarily service disruption, node crash, container host instability, or forced reboot. Because this issue was published recently, is not listed in CISA KEV, is not reported as ransomware-used, and has no known exploit maturity in the provided data, urgency is lower than for actively exploited kernel bugs; however, exposed multi-tenant Linux hosts, container platforms, and environments that allow untrusted users or workloads to create TIPC sockets should prioritize remediation.

How an attack unfolds

An attacker first needs the ability to exercise the Linux TIPC socket interface in a network namespace where TIPC is available. They then create or cause the accumulation of a very large number of TIPC sockets until the per-netns TIPC socket rhashtable reaches its maximum size, after which tipc_sk_insert() fails. The attacker then drives a TIPC accept() flow so that the kernel pre-allocates a child socket and calls tipc_sk_create() for it. When insertion fails, the kernel frees the internal socket object but leaves the outer socket pointer dangling. During cleanup of the failed accept(), the file/socket release path calls into tipc_release(), which sees a non-NULL pointer and calls lock_sock() on freed memory, causing a use-after-free write. In realistic scenarios, this is most likely to crash the kernel or destabilize the host; exploitation for code execution would require substantially more control over kernel heap layout and timing.

How to fix it

Upgrade the Linux kernel to a version that includes the TIPC fix that clears sock->sk on the failed tipc_sk_insert() path in tipc_sk_create(). If vendor packages are used, apply the relevant distribution kernel update rather than attempting to cherry-pick unless maintaining a custom kernel tree. Where immediate patching is not possible, reduce exposure by disabling or preventing use of the TIPC protocol where it is not required, restricting untrusted local users and containers from loading kernel modules or creating TIPC sockets, limiting capabilities such as CAP_NET_ADMIN and CAP_SYS_MODULE, enforcing container isolation controls, and monitoring or limiting abnormal socket creation. If TIPC is not operationally required, consider blacklisting the tipc kernel module or ensuring it is not auto-loaded.

How to confirm the fix worked

Confirm the running kernel is from a vendor release or custom build that contains the patch for the TIPC failed-insert cleanup path. Validate both the installed kernel package and the active booted kernel, because systems may require a reboot after kernel updates. Check whether the TIPC module is loaded or available using tools such as lsmod, modinfo, and kernel configuration review. If testing in a safe non-production environment, reproduce only with controlled kernel-debug tooling by exercising TIPC socket exhaustion and confirming the system no longer produces a KASAN use-after-free in lock_sock_nested/tipc_release when accept() fails. In production, avoid reproducing the exhaustion condition because it requires extreme socket counts and may destabilize the host.

Typical attack path

1. Identify a Linux system or container namespace where the TIPC protocol is enabled or can be loaded.
2. Obtain local code execution or workload execution rights sufficient to create AF_TIPC sockets, or otherwise interact with a TIPC listener capable of reaching the vulnerable accept path.
3. Create or retain a very large number of TIPC sockets in the same network namespace until the TIPC socket table reaches its maximum size.
4. Trigger a TIPC accept() operation that attempts to create a pre-allocated child socket after the table is exhausted.
5. Cause tipc_sk_create() to fail insertion, free the internal socket object, and leave a dangling sock->sk pointer.
6. Allow normal cleanup to release the failed accepted socket, causing tipc_release() to lock the freed socket and write to freed kernel memory.
7. Observe a kernel warning, KASAN report, oops, panic, or system instability; in a more advanced scenario, attempt to shape heap state for further exploitation.

How to detect it

Look for evidence of attempted or accidental triggering in kernel logs, crash dumps, and endpoint telemetry. Relevant sources include dmesg, journald kernel logs, /var/log/kern.log, /var/log/messages, syslog, kdump/vmcore analysis, KASAN/KFENCE reports, audit logs for module loading, and container/runtime telemetry showing unusual socket-heavy workloads. Suspicious signs include TIPC being loaded unexpectedly, a rapid increase in TIPC socket usage, warnings about TIPC port number exhaustion, kernel oops or panic events with stack traces containing tipc_sk_create(), tipc_accept(), tipc_release(), __sock_release(), or lock_sock_nested(), and resource exhaustion immediately preceding a crash. Because exploitation requires reaching roughly millions of sockets in a network namespace, correlate kernel errors with process accounting, cgroup metrics, file descriptor counts, and workload/container activity showing extreme socket creation. No public threat actors or active exploitation are identified in the provided data, so detection should focus on local abuse, denial-of-service attempts, fuzzing activity, and unexpected TIPC enablement.

• Socket create failed; port number exhausted
• BUG: KASAN: slab-use-after-free in lock_sock_nested
• slab-use-after-free in lock_sock_nested
• tipc_release
• tipc_accept
• tipc_sk_create
• tipc_sk_insert
• __sock_release
• sock_close
• lock_sock_nested
• net/tipc/socket.c
• net/core/sock.c
• AF_TIPC
• tipc

What your security team should do

• Inventory Linux systems where TIPC is enabled, loaded, or required, especially container hosts, multi-tenant compute nodes, and systems allowing untrusted local code execution.
• Prioritize kernel updates for systems that expose TIPC to untrusted users, workloads, or namespaces, even though the issue is not currently listed as KEV and has no known public exploit maturity.
• Disable or blacklist TIPC on systems that do not require it.
• Review container and workload policies to prevent unnecessary kernel module loading and restrict capabilities that make protocol and namespace abuse easier.
• Monitor for abnormal creation of AF_TIPC sockets, kernel warnings mentioning TIPC port exhaustion, and kernel crash signatures involving tipc_release or lock_sock_nested.
• Plan reboots after kernel updates and verify the fixed kernel is actually running.
• For custom kernels, ensure the specific fix sets sock->sk to NULL on the tipc_sk_insert() failure path before socket release cleanup can occur.