CVE-2026-68117: Patch TIPC-Enabled Linux Kernels

The CVE was published to the NVD on August 10, 2026, with kernel.org as the source. It has no NVD-assigned CVSS score, no CWE mapping, and no NVD exploit assessment yet. That absence should not be read as a clean bill of health; it means the vulnerability database has ingested the kernel’s technical record before completing its own enrichment.

The failure is in cleanup after socket exhaustion​

The bug sits in

, inside

. When TIPC cannot add a new socket to its per-network-namespace hash table, the function frees the newly allocated kernel socket structure with

, returns an error, and—before this fix—left the higher-level

pointer aimed at memory that had just been freed.

That stale pointer does not normally cause trouble on a straightforward

failure. As the kernel advisory explains, the ordinary syscall cleanup path clears the socket operations before release, so TIPC’s release handler is not called. The vulnerable route is the failure path for

, where TIPC has already allocated a child socket object for the connection.

On that path,

asks

to initialize the child socket. If insertion fails, the child’s

field remains non-null but dangling, and its operations pointer remains valid. The generic socket cleanup then releases the failed child, which reaches

and attempts to lock the supposedly live socket structure. It is no longer live.

The kernel report includes a KASAN-detected write-after-free in

, called through

,

, and the file-release path. This is a real memory-safety failure in kernel context, not merely an error return or resource-leak condition.

The correction is intentionally small: clear

when insertion fails.

already has a null-pointer check specifically intended for a preallocated child socket that failed during

. The bug existed because the creation routine violated that cleanup contract by leaving a non-null pointer behind. Clearing it lets the existing defensive check work.

Reaching the bug requires an extreme and specific condition​

This is not a typical packet-parsing flaw where one malformed network datagram is enough to reach vulnerable code. The failure condition is TIPC socket-table exhaustion inside a single network namespace. The kernel advisory says the relevant resizable hash table has a configured

of 1,048,576 buckets and reaches insertion failure at roughly two million TIPC socket entries; subsequent inserts return

.

That requirement sharply limits the systems that should treat this as an immediate operational emergency. A host must have TIPC compiled in or available as a module, the protocol must be enabled and used, and the relevant network namespace must be driven into a state holding about two million TIPC sockets. A failed

must then occur.

The flaw’s impact should therefore be described carefully. The kernel has confirmed a use-after-free write of a spinlock field under those conditions. The published record does not establish a remote code-execution path, a privilege-escalation technique, or in-the-wild exploitation. It also does not explain whether a realistic production workload can reach the table limit before other resource controls—memory limits, process limits, file descriptor limits, cgroup ceilings, or application backpressure—intervene.

That distinction matters in triage. A clustered or telecom-oriented environment that deliberately uses TIPC and permits untrusted workloads in shared network namespaces deserves prompt patching and configuration review. A general-purpose desktop, web server, or container host that does not load TIPC does not become exposed merely because its kernel version appears in the affected range.

The fixed kernel versions are clearer than the CVE’s older ranges​

The NVD’s kernel.org-supplied affected data identifies the flaw in source history beginning with commit

, the earlier TIPC change identified in the patch as the regression point. Its presentation is awkward for administrators because it combines Git commit ranges, older semver branch ranges, and newer release lines in one record.

The useful part for current fleets is the fixed-release list. The kernel CNA marks these releases as unaffected:

• Linux 6.6.148.
• Linux 6.12.101.
• Linux 6.18.42.
• Linux 7.1.6.
• Linux 7.2-rc5 and later mainline code carrying the fix.

The same record also describes older 4.9, 4.14, 4.19, 5.4, 5.10, 5.15, and 5.18 branch ranges as affected. Those versions are relevant to long-lived appliance images and vendors that continue carrying private kernel trees, but they should not be interpreted as a promise that every distribution bearing a superficially newer or older version string is in the same state.

Linux distributors routinely backport individual security patches without changing the upstream version in a way that makes a simple comparison reliable. The correct inventory test is the distribution’s kernel changelog, security advisory, or source package patch list. For self-built kernels, compare the source against the five stable backport commits listed in the CVE record or move to one of the fixed upstream releases.

LWN’s Linux 7.2-rc5 coverage independently lists the TIPC correction among the networking fixes in that release candidate. That confirms the patch reached mainline before the CVE was published, while the stable references in the NVD record show it was also backported to supported stable lines.

Stock WSL currently avoids the vulnerable protocol​

For Windows administrators, the important finding is in Microsoft’s own WSL2-Linux-Kernel source tree. Its current

configuration identifies itself as a 6.18.35.3 Microsoft-standard WSL2 kernel build and sets

to disabled.

That means the public configuration does not build TIPC into the kernel or as a loadable module. Since CVE-2026-68117 is in TIPC’s socket implementation, the normal Microsoft-supplied WSL kernel configuration is not exposed through this flaw even though the indicated base version, 6.18.35.3, predates upstream’s 6.18.42 fixed release.

This is exactly why version-only vulnerability reporting produces false positives. A scanner that matches only

against broad upstream version ranges may flag a WSL instance, while the relevant code is absent from the active kernel configuration. In this case, the configuration check changes the answer.

The exception is a custom WSL kernel. Microsoft documents that

can direct WSL 2 to boot an administrator-supplied kernel and modules VHD. Anyone using that facility, compiling a WSL kernel with

or

, or operating TIPC in a nested Linux VM should treat the upstream fixed releases as the floor. The same goes for container hosts using a custom kernel: network namespaces do not eliminate the issue, because the exhaustion threshold is assessed per namespace.

Administrators can establish relevance quickly with:

means the protocol is built in;

means it may be loadable;

means this CVE’s vulnerable component is absent. On a running system,

and

can help determine whether a modular build is available or active.

Patch the kernels that actually carry TIPC​

CVE-2026-68117 is a narrow kernel defect with a high trigger threshold, but its cleanup path writes through freed memory in kernel space. That is enough to justify remediation where TIPC is present and in use, particularly on shared hosts where a tenant or local workload could consume large socket counts within a network namespace.

The more immediate lesson is operational: do not turn an NVD “received” entry with no CVSS score into either panic or dismissal. Check the protocol configuration first, then the actual vendor kernel package. For standard WSL, Microsoft’s currently published kernel configuration already removes TIPC from the equation; for custom WSL kernels and TIPC-enabled Linux servers, the fixed kernel lines provide a concrete upgrade target.