CVE-2026-68137

What it actually does

This is a Linux kernel use-after-free in the X.25 networking stack. During X.25 neighbour teardown, x25_kill_by_neigh() iterates the global X.25 socket list and releases the list lock before it has taken a lifetime reference on the socket. A concurrent socket close through x25_release() can remove that socket from the list and free the underlying struct sock / struct x25_sock while the teardown path later locks or inspects it. The immediate impact is kernel memory corruption and likely denial of service through a kernel panic; depending on allocator state, timing, kernel hardening, and attacker control over reclaimed memory, use-after-free bugs in kernel networking code can sometimes be developed into local privilege escalation.

Why it matters to the business

Systems running an affected Linux kernel with X.25 support enabled may be vulnerable to crashes or potentially deeper kernel compromise if an attacker can exercise the X.25 socket and neighbour teardown paths. Because this issue is newly published and not currently listed in CISA KEV or marked as used in ransomware campaigns, immediate internet-scale exploitation is not indicated from the supplied data; however, kernel memory-safety flaws should still be prioritized on systems where the X.25 module is present, loaded, or usable by untrusted users. Operational consequences include unexpected host reboots, service interruption, degraded availability of workloads, and possible emergency patching if exploit code emerges.

How an attack unfolds

An attacker first identifies a Linux system where the X.25 networking code is available, either built into the kernel or loadable as a module. They then create or influence X.25 sockets and arrange for an X.25 neighbour to be torn down while another execution path closes an associated socket. The vulnerable code walks the global socket list and temporarily drops the list lock before holding a reference to the socket. In the race window, the close path can remove the same socket and free its memory. The neighbour teardown path then resumes and attempts to lock, inspect, or disconnect an object whose memory has already been freed. A basic exploit would repeatedly trigger this race to crash the kernel. A more advanced exploit would attempt heap grooming so the freed socket memory is reallocated with attacker-influenced contents before reuse, potentially turning the use-after-free into controlled kernel memory corruption.

How to fix it

Upgrade to a kernel version that contains the upstream fix for net/x25 x25_kill_by_neigh(), specifically the change that takes a temporary socket reference with sock_hold() while x25_list_lock still proves the socket list entry is live, rechecks the neighbour after lock_sock(), and restarts list walking after disconnects. No exact distribution package versions were provided, so use the relevant vendor kernel advisory for each Linux distribution and appliance. If immediate patching is not possible, reduce exposure by disabling or unloading X.25 support where it is not required, preventing automatic loading of the X.25 module, restricting untrusted local access, and limiting capabilities that allow network protocol/module manipulation. Because this is kernel code, service restarts alone are insufficient; the fixed kernel must be booted for remediation to take effect.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is a vendor build containing the X.25 fix. Check the active kernel version with uname -r and compare it to the distribution advisory or changelog for CVE-2026-68137 / net/x25 x25_kill_by_neigh(). Where source or build metadata is available, confirm the presence of the fix pattern: sock_hold() is taken while x25_list_lock is held, sock_put() releases the temporary reference, the neighbour is rechecked after lock_sock(), and iteration restarts safely after disconnect. Confirm whether X.25 is exposed by checking for a loaded x25 module, built-in X.25 support, or successful creation of AF_X25 sockets. After patching, reboot into the fixed kernel and verify that the vulnerable kernel is no longer running.

Typical attack path

1. Confirm that the target kernel includes X.25 support or can load the X.25 networking module.
2. Obtain the ability to create or interact with X.25 sockets and trigger relevant neighbour state changes.
3. Create X.25 socket activity associated with a neighbour entry.
4. Trigger neighbour teardown while concurrently closing or releasing the associated socket.
5. Win the race where x25_kill_by_neigh() drops x25_list_lock before the socket lifetime is pinned.
6. Cause the teardown path to operate on freed socket memory.
7. Use the resulting memory corruption to crash the kernel, or attempt heap grooming for stronger exploitation.

How to detect it

To assess prior exploitation, review kernel logs, crash dumps, audit logs, and endpoint telemetry for X.25-related kernel faults or suspicious AF_X25 socket use. Key sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg archives, kdump/vmcore analysis, kernel oops reports, KASAN/KFENCE reports, auditd syscall logs if socket creation is audited, and EDR telemetry for module loading or unusual socket activity. Look for slab-use-after-free reports, general protection faults, BUG/Oops traces, panics, or call traces containing x25_kill_by_neigh(), x25_release(), lock_sock(), or net/x25 symbols. Also review whether the x25 module was loaded unexpectedly, whether X.25 sockets were created by unusual processes, and whether crashes correlate with local user activity or repeated attempts to manipulate X.25 neighbour state. Absence of these artifacts does not prove absence of exploitation, because successful memory corruption may leave limited logs before a crash.

• slab-use-after-free in x25_kill_by_neigh
• x25_kill_by_neigh
• x25_release
• net/x25
• BUG: KASAN: slab-use-after-free
• KASAN: slab-use-after-free
• general protection fault
• kernel BUG
• Oops:
• Call Trace:
• AF_X25
• modprobe x25
• module x25
• /sys/module/x25
• /proc/net/x25

What your security team should do

• Prioritize patching Linux systems that have X.25 enabled, load the x25 module, provide shell access to untrusted users, or run multi-tenant workloads.
• Inventory kernels for X.25 support using module checks, kernel configuration, and package/version data from endpoint management tools.
• If X.25 is not operationally required, disable or blacklist the x25 module and prevent automatic module loading as a compensating control.
• Monitor vendor advisories for exact fixed kernel package versions because none were supplied in the input.
• Treat unexplained kernel panics involving x25_kill_by_neigh(), x25_release(), or AF_X25 activity as potentially suspicious until ruled out.
• Because the issue was published recently and has no supplied mature exploit status, continue monitoring exploit repositories, distribution advisories, and threat-intelligence feeds for changes in exploitation activity.
• After installing fixed packages, ensure systems are rebooted into the patched kernel; stale running kernels remain vulnerable.