CVE-2026-43093

What it actually does

This is a Linux kernel input-validation flaw in AF_XDP/XSK UMEM registration. The kernel did not sufficiently validate the relationship between UMEM headroom, tailroom, and the minimum usable XSK frame size. A local user able to configure AF_XDP/XSK UMEM could supply parameters that leave too little room for a minimum Ethernet frame or corrupt metadata such as skb_shared_info at the end of an XSK frame, especially in multi-buffer scenarios. The likely technical outcomes are kernel memory corruption, denial of service through a kernel crash, and potentially local privilege escalation depending on kernel configuration, allocator behavior, and exploit reliability.

Why it matters to the business

Successful exploitation could allow a local attacker or compromised low-privilege workload on a Linux host to crash the system or potentially gain elevated kernel-level privileges. This is most concerning for multi-user Linux systems, container hosts, network-processing servers, and environments where untrusted code can run on shared hosts. EPSS is currently very low and there is no known CISA KEV listing or public exploit maturity indicated, so broad internet-scale exploitation is not expected; however, the high CVSS impact means organizations should still prioritize patching systems where local users, containers, or exposed application workloads could reach AF_XDP/XDP-related functionality.

How an attack unfolds

An attacker first needs local code execution with sufficient permission to interact with AF_XDP/XSK socket functionality and register UMEM. The attacker creates or uses an AF_XDP socket, supplies crafted UMEM registration parameters with an unsafe combination of frame size, headroom, and effective tailroom, and then triggers packet-processing paths that rely on the incorrectly validated frame layout. Because the kernel accepted a layout that does not reserve enough usable space, packet or metadata handling can overwrite or corrupt adjacent frame metadata, including skb_shared_info in affected configurations. The immediate result may be a kernel warning, memory-safety fault, or host crash. With additional exploit development and favorable kernel conditions, the corruption could potentially be shaped into privilege escalation, but no public exploit maturity is currently reported.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the upstream fix tightening XSK UMEM headroom validation to account for tailroom and a minimum frame allowance. Because exact fixed package versions were not provided, use the relevant distribution advisory or kernel changelog for your platform and confirm that the patch for CVE-2026-43093, or the equivalent xsk/xdp_umem_reg UMEM validation fix, is included. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads on shared hosts, minimizing capabilities granted to containers, avoiding unnecessary CAP_NET_RAW/CAP_BPF/CAP_SYS_ADMIN-style privileges, and disabling or avoiding AF_XDP/XDP-based packet-processing features where they are not required. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, using commands such as uname -r and the distribution package manager. Verify against the vendor security advisory that the active kernel contains the fix for the XSK UMEM headroom/tailroom validation issue. If source or build metadata is available, confirm that xdp_umem_reg() validation accounts for minimum frame space and tailroom, including the skb_shared_info reservation used by multi-buffer handling. Validate that hosts have actually rebooted into the fixed kernel after patching. For exposure review, identify systems running AF_XDP/XDP workloads, packet-processing agents, high-performance networking software, or containers granted elevated networking capabilities. Kernel logs should also be reviewed for crashes or warnings involving xsk, AF_XDP, xdp_umem_reg, skb_shared_info, KASAN, or general protection faults before and after remediation.

Typical attack path

1. Obtain local execution on a vulnerable Linux system, such as through a compromised user account, workload, or application process.
2. Verify that the kernel supports AF_XDP/XSK and that the attacker has the required local privileges or capabilities to create and configure the relevant socket/UMEM objects.
3. Create an AF_XDP/XSK socket and register UMEM with crafted headroom/frame sizing that passes vulnerable validation but leaves insufficient room for packet data and tailroom metadata.
4. Trigger receive or multi-buffer packet-processing paths that use the malformed UMEM layout.
5. Cause kernel memory corruption, commonly resulting in a crash or instability; in a more advanced exploit, attempt to convert corruption into local privilege escalation.
6. Use elevated access or system disruption to further compromise workloads, disable services, or pivot from the affected host.

How to detect it

Look for evidence of local attempts to exercise AF_XDP/XSK UMEM registration followed by kernel memory faults, warnings, or crashes. Primary log sources include kernel ring buffer output, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd records, eBPF/XDP management logs, container runtime audit logs, and crash dump systems such as kdump, ABRT, apport, or systemd-coredump. Search for kernel oopses, panics, KASAN reports, general protection faults, or BUG/WARNING entries referencing xsk, AF_XDP, XDP UMEM, xdp_umem_reg, xsk_buff, skb_shared_info, or multi-buffer XDP receive paths. Investigate suspicious local processes that recently gained networking/BPF capabilities, created AF_XDP sockets, loaded or attached XDP/eBPF programs, or ran inside containers with elevated capabilities. Because this vulnerability does not produce a unique network signature and exploitation is local, absence of external scanning logs is not meaningful. Correlate kernel faults with recent user logins, container starts, package builds, privilege changes, or deployment of packet-processing software.

• xdp_umem_reg
• AF_XDP
• XSK
• xsk:
• xsk_buff
• skb_shared_info
• UMEM headroom
• UMEM tailroom
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at
• WARNING: CPU:
• Oops:
• Kernel panic - not syncing
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/net/xdp

What your security team should do

• Prioritize patching Linux hosts that run untrusted local workloads, shared shell environments, container platforms, network appliances, high-performance packet-processing services, or AF_XDP/XDP-based applications.
• Confirm reboot completion after kernel updates so the fixed kernel is active.
• Inventory systems using AF_XDP/XSK, XDP, eBPF networking, or privileged container networking capabilities to identify the most exposed assets.
• Temporarily reduce risk by removing unnecessary elevated Linux capabilities from containers and services, especially broad networking or BPF-related privileges.
• Monitor kernel logs and crash telemetry for signs of attempted exploitation or instability involving xsk, AF_XDP, UMEM registration, skb_shared_info, KASAN, or kernel memory corruption.
• Because EPSS is low, not KEV-listed, and no exploit maturity is reported, handle as important defense-in-depth patching rather than an emergency internet-facing incident unless local untrusted users or privileged containers are present.
• Update golden images, base AMIs, appliance builds, and container-host templates so newly deployed systems do not continue to boot vulnerable kernels.