CVE-2026-43092

What it actually does

This Linux kernel flaw affects AF_XDP socket binding with zero-copy UMEM configurations. The kernel did not validate whether the configured network device MTU could fit within the usable AF_XDP frame space after accounting for UMEM chunk size, headroom, and tailroom, or whether the hardware could satisfy the MTU given its supported receive buffer chaining limits. A local user with permission to create and bind AF_XDP sockets could supply an incompatible UMEM/frame configuration that the kernel accepts, potentially leading to receive-path failures, memory handling errors, or kernel instability resulting in denial of service. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, and high availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can disrupt Linux systems that expose AF_XDP functionality, particularly high-performance packet processing, observability, DDoS protection, firewalling, load-balancing, or network appliance workloads that rely on XDP/AF_XDP. The primary business risk is service interruption or host instability caused by a local low-privileged actor or a compromised local workload. The issue is not currently listed in CISA KEV, has no known ransomware association, has very low and flat EPSS, and has no reported public exploit maturity, so urgency is generally lower than for remotely exploitable kernel flaws; however, multi-tenant Linux systems, container hosts, network appliances, and systems granting packet-processing capabilities to non-root workloads should prioritize review.

How an attack unfolds

An attacker first obtains local code execution on a vulnerable Linux host with sufficient privileges or capabilities to create AF_XDP sockets and bind them to a network interface. They then create a UMEM region with chunk sizing, headroom, tailroom, or zero-copy parameters that leave insufficient usable frame space for the interface MTU, or that exceed the hardware receive-buffer segment limits exposed for XDP zero-copy. Because vulnerable kernels accepted this configuration during bind, the invalid setup can reach later packet processing paths. When traffic is received through the misconfigured AF_XDP path, the kernel or driver may be unable to handle packets safely within the advertised frame limits, leading to packet path failure, kernel warnings, crashes, or service disruption. Exploitation is local and availability-focused rather than a direct remote compromise path.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the AF_XDP fix validating MTU against usable frame size at bind time and checking the hardware receive buffer chaining constraints. No exact upstream or distribution package versions were provided in the input, so use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Where immediate patching is not possible, reduce exposure by limiting local users and workloads that can create AF_XDP sockets, restricting CAP_NET_RAW, CAP_NET_ADMIN, and related network capabilities in containers and service accounts, disabling or avoiding AF_XDP zero-copy usage where not required, and ensuring AF_XDP applications use UMEM chunk sizes and headroom/tailroom values that safely accommodate the interface MTU. On sensitive systems, consider disabling unneeded XDP/AF_XDP functionality or removing untrusted packet-processing workloads until patched.

How to confirm the fix worked

Confirm remediation by checking that the running kernel package includes the vendor fix for CVE-2026-43092 or the upstream change that validates AF_XDP MTU compatibility during bind. Verify the active kernel, not only the installed package, after reboot. Test exposure by attempting to bind an AF_XDP zero-copy socket with a UMEM usable frame size smaller than the configured interface MTU; a fixed kernel should reject the configuration at bind time rather than accepting it. Review network interface MTUs, AF_XDP application UMEM chunk sizes, configured headroom/tailroom, and NIC zero-copy capabilities to ensure operational configurations are valid. For containerized environments, validate that untrusted containers do not retain network capabilities that allow AF_XDP socket creation and binding.

Typical attack path

1. Gain local access to a vulnerable Linux system or compromise a workload running on it.
2. Obtain the privileges or Linux capabilities needed to open and bind AF_XDP sockets to a network interface.
3. Create an AF_XDP UMEM configuration with a usable frame size too small for the device MTU after headroom and tailroom are considered, or incompatible with the NIC zero-copy receive segment limits.
4. Bind the AF_XDP socket in zero-copy mode on a vulnerable kernel that does not reject the invalid configuration.
5. Trigger receive traffic through the affected interface and AF_XDP path.
6. Cause network processing failure, kernel instability, or a host-level denial of service.

How to detect it

Look for signs that a local process attempted to use AF_XDP zero-copy with invalid frame sizing and that the attempt coincided with kernel instability or network disruption. Useful log sources include kernel ring buffer output, system journal, syslog/kern.log, auditd records for processes with network capabilities, container runtime logs showing privileged or host-network containers, and EDR telemetry for processes creating AF_XDP sockets. Search for kernel messages mentioning AF_XDP, XSK, XDP zero-copy, UMEM, MTU, receive buffer segments, driver reset, page/pool errors, warnings, oopses, panics, soft lockups, or network device crashes around the time of outage. Correlate these with recent execution of packet-processing tools, custom AF_XDP applications, privileged containers, or newly launched binaries. Because exploitation is local and the vulnerability description does not provide a unique crash signature, detection should focus on correlation between AF_XDP activity, suspicious local process execution, elevated network capabilities, and kernel availability events rather than a single definitive indicator.

• AF_XDP
• XSK
• xsk
• XDP zero-copy
• zero-copy
• UMEM
• xdp_zc_max_segs
• MTU
• kernel panic
• kernel BUG
• kernel NULL pointer dereference
• kernel oops
• WARNING: CPU
• soft lockup
• NETDEV WATCHDOG
• page_pool
• privileged container
• CAP_NET_ADMIN
• CAP_NET_RAW

What your security team should do

• Inventory Linux systems running workloads that use XDP, AF_XDP, zero-copy packet processing, high-performance telemetry, network security tools, load balancers, or custom packet capture applications.
• Prioritize patching multi-tenant hosts, container platforms, network appliances, and systems where non-root or semi-trusted workloads have network capabilities.
• Apply the relevant vendor kernel update and reboot into the fixed kernel; verify the running kernel version after maintenance.
• Restrict CAP_NET_RAW, CAP_NET_ADMIN, privileged containers, host networking, and direct access to network interfaces for workloads that do not explicitly require AF_XDP.
• Audit AF_XDP applications for UMEM chunk size, headroom, tailroom, MTU, and zero-copy assumptions, and update configurations that depend on undersized frames.
• Monitor kernel logs for AF_XDP, XDP, driver, or page/panic warnings on systems using zero-copy packet processing.
• Because EPSS is very low and flat, KEV status is false, and exploit maturity is none, handle as a defense-in-depth and availability-hardening patch unless the environment exposes AF_XDP to untrusted local workloads.