CVE-2026-45886

What it actually does

The flaw is an incorrect eBPF verifier/helper prototype for bpf_xdp_store_bytes in the Linux kernel. The helper’s third argument was treated as writable uninitialized memory instead of read-only source memory, causing the verifier to perform the wrong access checks. This can incorrectly reject valid XDP/eBPF programs that read from BPF maps marked read-only to programs, and in some cases can allow unsafe handling of uninitialized memory semantics. The practical impact is availability-oriented: BPF/XDP programs may fail to load or attach, disrupting kernel-level packet processing or networking components that depend on them.

Why it matters to the business

Organizations using Linux systems with eBPF/XDP-based networking, observability, load balancing, or security tooling may experience service degradation or outages if affected BPF programs fail verification or cannot attach. The issue is local and has low public exploitation signal: it is not in CISA KEV, is not known to be used in ransomware campaigns, has no known exploit maturity, and has a low EPSS score of 0.0016. However, systems that rely on eBPF-heavy platforms such as container networking or high-performance packet processing should still prioritize remediation because failures can affect network availability.

How an attack unfolds

An attacker first needs local ability to load or influence eBPF/XDP programs, which commonly requires CAP_BPF, CAP_SYS_ADMIN, privileged container access, or an environment where unprivileged BPF loading is enabled. The attacker crafts or triggers loading of an XDP program that calls bpf_xdp_store_bytes with memory sourced from a read-only BPF map or otherwise exercises the incorrect helper argument semantics. The kernel verifier then applies the wrong memory-access rule, producing verifier failures or unsafe memory-handling behavior. In an operational environment, this can prevent BPF programs from loading or attaching, which can interrupt dataplane functions, packet filtering, NAT, service routing, or observability agents that depend on those programs.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the upstream fix for the bpf_xdp_store_bytes helper prototype. No specific fixed package versions were provided in the input, so use the vendor advisory for the affected distribution/kernel stream to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling unprivileged BPF where operationally feasible, limiting CAP_BPF and CAP_SYS_ADMIN to only trusted workloads, preventing privileged containers from loading arbitrary BPF programs, and restricting who can attach XDP programs to network interfaces. Test eBPF/XDP-dependent components after patching, especially CNI, service mesh, load-balancing, observability, and packet-filtering agents.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build that contains the bpf_xdp_store_bytes prototype fix. Validate exposure by checking whether BPF loading is available to unprivileged users and whether workloads have CAP_BPF, CAP_SYS_ADMIN, or privileged container permissions. Functionally validate the fix by loading a known-good XDP/eBPF program that calls bpf_xdp_store_bytes using data from a read-only-to-program map and confirming that it passes verification and attaches successfully. Review kernel logs for the absence of verifier errors such as 'write into map forbidden' during BPF program load attempts. Use bpftool or equivalent platform tooling to confirm expected programs are loaded and attached after reboot and after agent restarts.

Typical attack path

1. Obtain local code execution or access to a privileged container/user context capable of loading eBPF programs.
2. Check whether BPF loading is permitted through capabilities such as CAP_BPF or CAP_SYS_ADMIN, or whether unprivileged BPF is enabled.
3. Prepare an XDP/eBPF program that invokes bpf_xdp_store_bytes and passes memory in a way that exercises the incorrect helper prototype, such as using data sourced from a BPF_F_RDONLY_PROG map.
4. Attempt to load or attach the program to an interface or datapath.
5. Trigger verifier rejection or related BPF loading failure, causing dependent networking or packet-processing functionality to fail or remain unloaded.

How to detect it

Look for evidence of attempted or failed BPF/XDP program loading rather than remote network exploitation. Relevant sources include kernel logs, dmesg, journald, auditd records for the bpf syscall, endpoint telemetry showing bpftool or custom BPF loaders, container runtime logs for privileged workloads, and logs from eBPF-based agents such as networking, observability, or security tools. Search for verifier messages referencing bpf_xdp_store_bytes, read-only BPF maps, or 'write into map forbidden'. Also review audit logs for unexpected BPF_PROG_LOAD activity by non-administrative users, unusual privileged containers, or processes that normally should not load BPF programs. Since no public exploitation or named threat actor activity is known from the provided data, treat detections as suspicious when they occur outside expected BPF management processes or coincide with network-agent failures, interface attach failures, or sudden loss of XDP programs.

• write into map forbidden
• bpf_xdp_store_bytes
• call bpf_xdp_store_bytes#190
• BPF_F_RDONLY_PROG
• ARG_PTR_TO_UNINIT_MEM
• PTR_TO_MAP_VALUE
• failed to load BPF program
• BPF_PROG_LOAD
• XDP program failed to attach
• bpftool prog load
• bpftool net attach
• unprivileged_bpf_disabled

What your security team should do

• Prioritize patching Linux hosts that run eBPF/XDP-heavy networking, observability, or security components, because the primary risk is disruption of kernel-level dataplane functionality.
• Inventory systems that permit local users, containers, or agents to load BPF programs, including hosts with CAP_BPF, CAP_SYS_ADMIN, privileged containers, or unprivileged BPF enabled.
• Disable unprivileged BPF where feasible and enforce least privilege for workloads that require BPF access.
• Monitor kernel, audit, and agent logs for repeated BPF verifier failures involving bpf_xdp_store_bytes or read-only BPF maps.
• After patching, restart or roll affected eBPF-dependent agents and verify that expected BPF programs are loaded and attached.
• Because EPSS is low, exploit maturity is none, and the issue is not in KEV, prioritize based on operational dependence on eBPF/XDP rather than internet exposure alone.