CVE-2026-68137: Linux X.25 Flaw Requires X.25 Enabled

The practical issue is more specific than the CVE headline suggests. X.25 maintains a global list of sockets, and the vulnerable path scans that list when an X.25 neighbour—the kernel object representing a connected X.25 link—is terminating. The list lock establishes that a socket is currently on the list, but the older code dropped that lock before acquiring the individual socket lock. A simultaneous close could then remove and free the same socket, leaving the neighbour-teardown routine to lock or inspect memory that no longer represents a live socket.

NVD’s description says a QEMU run with KASAN, Linux’s kernel memory-error detector, reproduced the condition against the development tree. That establishes a kernel memory-safety failure; it does not establish a public exploit, a CVSS severity, or remote reachability. As of August 11, NVD has assigned no CVSS vector or score and no CWE classification, and it names no affected distribution packages. Those omissions should govern how administrators prioritize the advisory: patch normally and promptly where X.25 is enabled, but do not mistake an unscored, configuration-dependent bug for evidence of an internet-wide attack path.

The race begins after a lock that looked sufficient​

The vulnerable sequence stems from a change intended to solve an earlier X.25 concurrency problem. The Linux networking code needs to disconnect virtual circuits associated with a neighbour whose link is being torn down. It cannot keep the global

while taking each socket’s own lock, because doing so risks lock-order problems and long lock holds.

The older implementation therefore released

, called

, disconnected the socket, released the socket lock, and resumed its traversal. That sequence treated membership in the list as though it guaranteed the socket’s lifetime beyond the lock scope. It does not.

While the global lock was absent, another thread could execute

, remove the socket from

, and drop its final reference. When the teardown routine resumed, its

pointer could refer to freed memory. The failure is a classic lifetime race: a lock protects discovery, but no reference count protects use after discovery.

David Lee’s patch takes a temporary socket reference with

while the list lock still proves that the entry is live. Only then does it drop the list lock and obtain the individual socket lock. Once it holds that lock, the revised code checks again that

is still the same neighbour before disconnecting it, releases the socket, drops the temporary reference, and restarts the list walk.

The restart is substantive, not defensive clutter. The function has released the global list lock during the work, so its previous iterator state cannot safely be reused. A socket may have been removed, inserted, or otherwise changed while the lock was absent. Continuing from an old list position could create a separate correctness problem even after the use-after-free is fixed.

A 2022 synchronization fix created the opening​

The CVE’s affected range begins with upstream commit

, a 2022 X.25 fix that added

in

. That earlier patch addressed a different race: X.25 disconnects clear the socket’s neighbour pointer, and code concurrently sending, receiving, or connecting could otherwise dereference that pointer after it became

.

The Linux kernel archive’s record for Linux 7.2-rc5 includes the new “fix use-after-free in

” patch, while the Syzbot CI index records a completed test run for the change on July 20. Together, those records show this was treated as a kernel correctness repair and merged into the development stream before the CVE appeared in NVD.

The important historical point is that locking a socket after leaving the list lock repaired one race but left the lifetime gap. The code had synchronization, just not the reference ownership needed to make its pointer durable across the synchronization boundary. The new patch closes that gap and then handles the state changes made possible by waiting for the socket lock.

This is not unusual in kernel maintenance: concurrency fixes often expose the distinction between mutual exclusion and object lifetime. The former controls who can modify an object at a moment in time; the latter guarantees the object still exists when a thread finally gets its turn. CVE-2026-68137 is the latter problem.

X.25 exposure is the deciding condition​

Linux still ships X.25 support as the

kernel option. The Linux Kernel Driver Database describes it as a tristate option—built in, modular, or absent—with the module named

. Its own current configuration tracking shows the option remains present through Linux 7.2 release candidates.

That does not mean it is enabled on a particular server, workstation, appliance, container host, or WSL distribution. In many modern environments it will be omitted from the active kernel configuration, compiled as an available-but-unloaded module, or simply unused because no X.25 interfaces, LAPB links, or AF_X25 applications exist. The vulnerability is in code that must be present and exercised; ordinary IPv4, IPv6, TCP, UDP, Wi-Fi, Ethernet, and VPN use do not invoke

.

Administrators should establish exposure from the running kernel rather than infer it from the Linux version string alone:

grep '^CONFIG_X25=' /boot/config-$(uname -r) 2>/dev/null
zgrep '^CONFIG_X25=' /proc/config.gz 2>/dev/null
modinfo -F filename x25 2>/dev/null
lsmod | grep '^x25 '

A result of

, no installed

module, and no built-in X.25 support materially reduces this CVE to a non-applicable code path for that kernel. A built-in or loadable module only establishes that the code exists; an organization should also identify whether AF_X25 sockets and X.25 network links are actually in use before assigning emergency-change priority.

For Windows-focused environments, the distinction is especially useful. Windows itself is not affected by this Linux kernel CVE. The relevant systems are Linux guests in Hyper-V, Linux appliances, bare-metal Linux systems, CI runners, and possibly WSL2 environments where the supplied or custom kernel includes X.25 support. The host operating system label is not the deciding factor; the running Linux kernel configuration is.

NVD lists backports, but not usable fixed package versions​

NVD references five kernel.org stable-tree commits:

,

,

,

, and

. Their presence is evidence that the repair has been backported into multiple stable branches.

What NVD does not yet provide is the piece most operators need: a clear mapping from those commit IDs to named stable releases and distribution package versions. The CVE record’s affected-data section is Git-centric and includes historical version boundaries associated with earlier backports, but it does not tell a Debian, Ubuntu, Red Hat, SUSE, Oracle Linux, or appliance administrator which vendor kernel build first carries this exact repair.

That gap has a direct operational consequence. Do not close the finding merely because a distribution’s kernel version looks newer than the 2022 code change that introduced the risky locking pattern. Instead, use the vendor’s security advisory or kernel changelog to confirm that it contains the

lifetime fix, or verify the presence of the stable backport in the vendor source package. At publication time, no distribution-specific fix announcements were listed in the NVD record.

Patch by normal kernel maintenance, not by panic response​

The appropriate response is straightforward:

• Update affected Linux kernels through the normal vendor-supported channel, prioritizing hosts that use X.25 or deliberately retain the x25 module.
• Reboot into the updated kernel, because this defect lives in kernel memory-management and networking code; installing a package without changing the running kernel does not remove the vulnerable path.
• If X.25 is not required, remove it from custom kernel configurations or prevent the x25 module from loading as part of protocol-surface reduction.
• Track the distribution package advisory rather than relying on NVD’s current lack of a CVSS score as a statement that the flaw is harmless.

CVE-2026-68137 is a narrowly scoped repair to a legacy protocol subsystem, but the code pattern is serious: a concurrent close can turn an ordinary socket pointer into freed kernel memory during neighbour teardown. The patch is already moving through stable Linux maintenance. The remaining work for operators is to determine whether their kernels contain and expose X.25, then confirm their vendor build includes this particular backport rather than assuming that any recently updated kernel does.