CVE-2026-43011

What it actually does

CVE-2026-43011 is a Linux kernel memory-corruption flaw in the X.25 networking stack. Under an error path in x25_queue_rx_frame(), an sk_buff can be freed when alloc_skb() fails, while the caller chain can later treat the frame as unqueued and call kfree_skb() on the same sk_buff again in x25_backlog_rcv(). This double free can corrupt kernel heap state, potentially causing a kernel panic, denial of service, or, in worst-case conditions, kernel-level code execution or privilege escalation. The CVSS vector indicates network reachability, low attack complexity, no authentication, and no user interaction, but practical exploitability depends heavily on whether X.25 support is enabled, reachable, and whether the attacker can reliably shape memory pressure and packet flow.

Why it matters to the business

Organizations running affected Linux kernels with X.25 networking enabled or reachable could experience unplanned host crashes, service outages, or potential full system compromise at the kernel level. Although EPSS is currently low and stable, the vulnerability has a high severity rating because successful exploitation affects confidentiality, integrity, and availability of the entire host. Systems using legacy telecommunications, industrial, payment, or specialized WAN environments where X.25 remains enabled should treat this as higher priority than general-purpose systems where X.25 is disabled or unavailable.

How an attack unfolds

An attacker first identifies a Linux system where the X.25 protocol stack is enabled and reachable through an exposed interface or service path. The attacker then sends X.25 traffic designed to reach the receive-frame processing path while also attempting to create conditions where alloc_skb() fails, such as by increasing memory pressure or triggering repeated allocations. When x25_queue_rx_frame() encounters the allocation failure, it frees the sk_buff and returns an error. The error is propagated in a way that causes the upper receive path to believe the frame was not queued, causing x25_backlog_rcv() to free the same sk_buff again. The resulting double free corrupts kernel memory and may crash the system immediately or create exploitable heap state. No public exploit maturity or known KEV exploitation is currently indicated, so defenders should focus on exposure reduction, patching, and crash/memory-corruption telemetry.

How to fix it

Apply the Linux kernel update provided by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer that includes the net/x25 fix for the double free in x25_queue_rx_frame()/x25_backlog_rcv(). No exact fixed package versions were provided in the input, so remediation should be tracked against vendor advisories for the deployed kernel branch. If immediate patching is not possible, reduce exposure by disabling X.25 support where not required, unloading and blacklisting the x25 module if it is modular, rebuilding kernels without CONFIG_X25 where feasible, and restricting access to any interfaces or networks that can deliver X.25 traffic. Reboot systems after kernel updates so the patched kernel is actually running.

How to confirm the fix worked

Confirm the running kernel version with uname -r and compare it to the fixed kernel version listed by the applicable vendor advisory. Verify that the system has booted into the patched kernel after update, not merely installed it. Check whether X.25 support is present or active by reviewing kernel configuration for CONFIG_X25, loaded modules such as x25, module metadata, and X.25 procfs entries where present. On source-managed kernels, confirm the applied patch changes the X.25 receive error path so the same sk_buff cannot be freed both in x25_queue_rx_frame() and again by x25_backlog_rcv(). For mitigation validation, confirm the x25 module cannot be loaded automatically, is not currently loaded, and that X.25 interfaces or network paths are not reachable unless explicitly required.

Typical attack path

1. Identify Linux systems with X.25 protocol support enabled or the x25 kernel module loadable.
2. Establish network reachability to the X.25 receive path through a relevant interface, socket, or connected X.25 network segment.
3. Send crafted or high-volume X.25 frames that exercise x25_queue_rx_frame() and x25_state3_machine() processing.
4. Create or wait for memory allocation pressure so alloc_skb() fails in the vulnerable error path.
5. Trigger the vulnerable call chain where the same sk_buff is freed in x25_queue_rx_frame() and then again in x25_backlog_rcv().
6. Leverage the resulting kernel heap corruption to cause denial of service or attempt more advanced kernel exploitation.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, persistent journal entries, crash dumps, and monitoring alerts for signs of X.25 receive-path crashes or kernel heap corruption. Relevant log sources include dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald, netconsole output, kdump/vmcore data, kernel panic records, hypervisor reset events, and endpoint telemetry that captures kernel oopses. Focus searches around function names x25_queue_rx_frame, x25_state3_machine, x25_process_rx_frame, x25_backlog_rcv, kfree_skb, and alloc_skb, as well as allocator diagnostics such as double free, use-after-free, slab corruption, KASAN, KFENCE, BUG, Oops, panic, and general protection fault. Correlate any such events with inbound X.25 traffic, unexpected loading of the x25 module, sudden memory pressure, and unexplained host reboots. Because exploitation may leave little application-level evidence, absence of application logs does not rule out exploitation; kernel telemetry and crash artifacts are the primary evidence sources.

• x25_queue_rx_frame
• x25_state3_machine
• x25_process_rx_frame
• x25_backlog_rcv
• kfree_skb
• alloc_skb
• x25_backlog_rcv:
• net/x25/x25_in.c
• BUG: KASAN: double-free
• KASAN: double-free
• double free
• use-after-free
• slab corruption
• kernel BUG
• Oops:
• general protection fault
• Kernel panic
• BUG: unable to handle kernel
• x25
• CONFIG_X25
• /proc/net/x25
• /sys/module/x25
• x25.ko

What your security team should do

• Prioritize patching Linux systems that have X.25 enabled, are connected to legacy telecom/WAN environments, or run kernels supplied by appliances or embedded distributions where protocol modules may be enabled by default.
• Inventory exposure by searching for kernels with CONFIG_X25 enabled, the x25 module loaded or loadable, and any active X.25 configuration or interfaces.
• If X.25 is not required, disable it, unload the module, and add module blacklist controls to prevent automatic loading until patched kernels are deployed.
• Monitor kernel logs for X.25-related crashes, double-free reports, KASAN findings, slab allocator corruption, and unexplained reboots.
• Treat any confirmed kernel memory-corruption event on an exposed system as a potential compromise and perform forensic triage, even though there is no current KEV listing or known mature public exploit.
• Coordinate with vendors for appliances, network gateways, industrial systems, and embedded Linux devices, because kernel fixes may be delivered through firmware or platform updates rather than normal OS package channels.