CVE-2026-64355

What it actually does

This Linux kernel flaw affects BPF/XDP devmap broadcast redirect handling. When an XDP program redirects a fragmented or multi-buffer packet through a devmap broadcast path, the kernel clone logic copies only the linear xdp_frame data but can leave the XDP_FLAGS_HAS_FRAGS state set without valid fragment metadata. During later frame cleanup, the kernel may interpret uninitialized tailroom as skb_shared_info, causing an out-of-bounds memory access in kernel context. The practical impact is kernel memory corruption that can lead to denial of service through kernel panic and, depending on allocator state, kernel configuration, and exploit reliability, may expose a path toward privilege escalation or code execution. Exploitation requires a vulnerable kernel and an active XDP/devmap configuration that processes attacker-controlled network traffic.

Why it matters to the business

Systems using Linux kernel XDP/BPF devmap broadcast or redirect functionality on network-facing interfaces may be remotely destabilized by crafted traffic, causing outages on load balancers, packet filters, DDoS appliances, container networking nodes, routers, firewalls, or other high-throughput Linux networking systems. Although this issue is not listed in CISA KEV and has low EPSS at the time of assessment, its network-triggerable kernel impact and high CVSS score make it important for organizations that rely on XDP-based networking, especially where kernel crashes would interrupt critical traffic forwarding.

How an attack unfolds

An attacker first identifies a Linux system that accepts network traffic on an interface using XDP with devmap redirect or broadcast behavior. The attacker then sends fragmented, nonlinear, jumbo, or otherwise multi-buffer packet frames that reach the vulnerable XDP path. During devmap broadcast redirect, the kernel clones the packet for multiple destinations. In vulnerable versions, the clone operation does not correctly preserve valid fragment metadata for fragmented XDP frames while still marking the frame as fragmented. When the cloned frame is later returned or freed, the kernel cleanup path treats uninitialized tail data as skb_shared_info and performs an out-of-bounds access. This can crash the kernel and may create memory corruption conditions with confidentiality, integrity, and availability consequences. There is no public exploit maturity indicated, and exploitation is expected to depend heavily on the target’s XDP configuration, NIC driver behavior, packet layout, and kernel hardening options.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the fix for rejecting fragmented frames in devmap clone paths, specifically the kernel change titled "bpf: Reject fragmented frames in devmap." No exact fixed package versions were provided in the input, so use the relevant distribution or appliance vendor advisory to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling or removing XDP programs that use devmap broadcast redirects, avoiding XDP multi-buffer/fragment support on affected interfaces, disabling jumbo frames where operationally feasible, changing XDP programs to avoid clone-based devmap broadcast for fragmented traffic, and moving exposed services behind filtering that drops unexpected fragmented or oversized frames. Disabling unprivileged BPF can reduce local abuse and unauthorized setup of BPF programs, but it does not mitigate remote triggering on systems that already run vulnerable XDP/devmap programs.

How to confirm the fix worked

Confirm the running kernel includes the vendor backport or upstream fix that rejects fragmented frames in devmap clone paths. Validate by checking kernel package changelogs, distribution security advisories, or source patches for the "bpf: Reject fragmented frames in devmap" change. Use bpftool and ip link to inventory XDP programs and devmap/devmap_hash usage on network interfaces. After remediation, perform controlled lab testing with fragmented, jumbo, or multi-buffer traffic against an XDP/devmap broadcast configuration and confirm the traffic is rejected or handled without kernel oops, KASAN reports, or panic. Also verify that the running kernel version after reboot matches the patched kernel and that no vulnerable alternate boot kernel remains selected.

Typical attack path

1. Identify or infer a Linux network-facing system using XDP/BPF for packet forwarding, filtering, load balancing, or DDoS mitigation.
2. Send crafted traffic that produces fragmented, nonlinear, jumbo, or multi-buffer packet frames on the XDP receive path.
3. Ensure the traffic is processed by an XDP program that performs devmap redirect or devmap broadcast cloning.
4. Trigger the vulnerable clone path where fragment state is retained but fragment metadata is not validly copied.
5. Cause the kernel frame return/free path to interpret uninitialized memory as skb_shared_info.
6. Achieve a kernel out-of-bounds access, commonly resulting in kernel oops, panic, networking disruption, or potentially exploitable memory corruption.

How to detect it

Retrospective detection should focus on kernel-level artifacts because the malicious packet content may not be retained after exploitation. Review syslog, journald, dmesg, kernel crash dumps, kdump/vmcore data, KASAN reports, panic logs, hypervisor console logs, and network appliance event logs for crashes or memory errors involving XDP, BPF devmap, skb_shared_info, or xdp_frame return/free paths. Correlate any kernel oops or reboot events with spikes in fragmented, oversized, jumbo, malformed, or multi-buffer traffic on interfaces using XDP. Inspect BPF/XDP configuration using bpftool to determine whether devmap or devmap_hash maps and redirect/broadcast programs were loaded at the time. If packet telemetry is available, look for unusual volumes of IPv4 fragments, IPv6 fragment headers, large frames, or MTU-edge traffic immediately preceding kernel instability. There are no known public threat actors or ransomware campaigns associated with this vulnerability in the supplied data, so detection should emphasize behavioral correlation rather than actor-specific indicators.

• skb_shared_info
• XDP_FLAGS_HAS_FRAGS
• dev_map_enqueue_clone
• dev_map_redirect_clone
• xdp_return_frame
• xdp_frame
• devmap
• devmap_hash
• bpf: Reject fragmented frames in devmap
• BUG: KASAN: out-of-bounds
• BUG: unable to handle kernel paging request
• kernel panic
• Oops:
• general protection fault
• skb_shared_info in tailroom
• xdp_do_redirect
• bpf_redirect_map

What your security team should do

• Prioritize patching network-facing Linux systems that run XDP/BPF programs with devmap redirect, devmap_hash, or broadcast forwarding behavior.
• Inventory XDP usage with bpftool, ip link, orchestration tooling, and appliance configuration management to identify where devmap-based forwarding is enabled.
• If patching is delayed, temporarily disable XDP devmap broadcast paths or modify XDP programs to drop fragmented or multi-buffer frames before devmap redirect.
• Review kernel crash, oops, panic, KASAN, and watchdog logs for evidence of recent out-of-bounds access in XDP, devmap, skb_shared_info, or xdp_return_frame paths.
• Limit exposure of affected interfaces to untrusted traffic where possible, and filter unexpected fragmented, jumbo, or malformed packets upstream.
• Track vendor advisories for exact fixed kernel package versions because fixed versions were not supplied in the vulnerability metadata.
• Do not rely on the current low EPSS or absence from KEV as a reason to defer remediation on systems where XDP is part of critical traffic forwarding.