Linux kernel BPF devmap: cloning fragmented XDP frames for broadcast redirect reads out of bounds

Impact

On a broadcast redirect through a devmap, the kernel clones the packet for every destination but the last. For native XDP the clone copies only the linear xdp_frame, so a multi-buffer (fragmented) frame keeps XDP_FLAGS_HAS_FRAGS set with no valid fragment metadata; the free path then reads uninitialised tailroom as skb_shared_info and accesses memory out of bounds. The practical effect is host kernel memory corruption or a panic on a node running an XDP program that uses bpf_redirect_map broadcast - which is a real configuration on GPU clusters using Cilium or a similar eBPF dataplane, and a kernel panic there takes the whole node and every colocated training job with it. The fix rejects fragmented frames in dev_map_enqueue_clone() and in the generic-XDP clone path rather than repairing the copy. NVD scores this AV:N/PR:N, which reflects automated kernel-CNA scoring rather than the actual path: reaching the bug requires a program already loaded and attached by a privileged component.

Who can reach it

Local and privileged: whoever can load and attach an XDP program with a broadcast bpf_redirect_map - root, or a container holding CAP_BPF and CAP_NET_ADMIN. Once such a program is attached, the out-of-bounds access is driven by ordinary traffic carrying multi-buffer frames (large MTU or jumbo frames on the data path). An unprivileged tenant pod with a stock capability set cannot attach the program itself.

What to do

Take the stable-kernel backport (five branch commits are linked on the record; no distro fixed-version is stated in the record itself) and reboot each node - this is a kernel data-path fix, not livepatchable in the general case. Until nodes are rebooted, the exposure is limited to whether any attached XDP program actually performs broadcast redirects through a devmap, so auditing the CNI/eBPF dataplane configuration is a cheap way to decide how urgent the drain window is.

References

Related entries

• Linux kernel krb5 crypto: use-after-free when an async AEAD backend is bound to the enctypeCVE-2026-64439 · Linux kernel krb5 crypto helpers (rfc3961_simplified / rfc8009_aes2 AEAD paths)Critical
• Linux kernel (drivers/nvme/target): A client connected to your NVMe-oF TCP target can drive a reference-count underflowCVE-2026-64534 · Linux kernel (drivers/nvme/target)Critical
• Linux kernel NVMe-oF TCP target (nvmet-tcp, data-digest mismatch handling): With data digests enabled, a digestCVE-2026-64535 · Linux kernel NVMe-oF TCP target (nvmet-tcp, data-digest mismatch handling)Critical
• Linux kernel SMC-R connection data control (smc_cdc_rx_handler socket lifetime): The CDC receive handler looks theCVE-2026-64541 · Linux kernel SMC-R connection data control (smc_cdc_rx_handler socket lifetime)Critical
• Linux kernel (net/xfrm): The same ownership-marker bug as CVE-2026-53363, in the other IPTFS frag-transfer helper.CVE-2026-64566 · Linux kernel (net/xfrm)Critical
• Linux kernel libceph: malicious OSD triggers out-of-bounds reads in RBD lock-info decodeCVE-2026-68082 · Linux kernel libceph (decode_lockers() in cls_lock_client.c)Critical