critical CVSS 9.8

CVE-2026-64355·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: bpf: Reject fragmented frames in devmap Devmap broadcast redirects clone the packet for all but the last destination. For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return. Reject fragmented native XDP frames in dev_map_enqueue_clone(). Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.

Severity
critical
Software
Kernel
Fixed in
7.1.4
Published
2026-07-25

Affected versions

From: 6.19

Until: 7.1.4

Fixed in: 7.1.4

How to fix this CVE

Update your Linux kernel to version 7.1.4 or later to patch the memory safety issue in eBPF devmap packet cloning. This vulnerability affects packet forwarding in XDP programs when fragmented frames are cloned for broadcast operations. Apply the kernel update and reboot your system to eliminate the risk of out-of-bounds memory access.

sudo dnf update kernel kernel-devel kernel-headers

Defensia detects this vulnerability

How to check if you are affected

  1. Run 'uname -r' to verify your current kernel version; versions 6.19.x through 7.1.3 are vulnerable
  2. Check if XDP programs are loaded on your system with 'ip link show' and inspect for any devmap redirect or broadcast operations in active eBPF programs
  3. Search kernel logs for memory access errors: 'dmesg | grep -i "out of bounds\|segfault\|BUG"' which may indicate exploitation attempts
  4. Confirm the fix by upgrading to kernel 7.1.4+ and verifying with 'uname -r' after reboot, then validate eBPF programs reload without errors

FAQ

What is CVE-2026-64355?

This vulnerability affects Linux kernel eBPF packet processing, specifically the devmap redirect mechanism used in XDP programs. When fragmented packets are cloned for broadcast operations, incomplete metadata leaves the frame in an invalid state, allowing uninitialized memory to be interpreted as packet structures during cleanup, causing an out-of-bounds read.

Is CVE-2026-64355 being actively exploited?

No, this vulnerability is not currently listed in CISA's Known Exploited Vulnerabilities catalog and no public exploits are available, though the memory safety issue makes it a valuable target for determined attackers.

What versions of Kernel are affected by CVE-2026-64355?

Linux kernel versions 6.19 through 7.1.3 are vulnerable; version 7.1.4 and later include the fix.

How do I check if my server is vulnerable to CVE-2026-64355?

Run 'uname -r' and compare your version against the vulnerable range (6.19-7.1.3). Additionally, confirm XDP is in use with 'ethtool -i <interface>' or 'ip link show' for BPF programs, as the vulnerability only affects systems actively using XDP devmap redirects.

Does Defensia detect CVE-2026-64355?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If Kernel is installed on a monitored server, CVE-2026-64355 will appear in your dashboard with remediation steps.

Related Kernel CVEs

CVE-2026-64055CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Carry over frag counter The gmac_rx() NAPI poll function assembles packets in an SKB from a ring buffer. If the ring buffer gets completely emptied during a poll cycle, we exit gmac_rx(), but the packet is not yet completely assembled in the SKB, yet the fragment counter frag_nr is reset to zero on the next invocation. Solve this by making the RX fragment counter a part of the port struct, and carry it over between invocations. Reset the fragment counter only right after calling napi_gro_frags(), on error (after calling napi_free_frags()) or if stopping the port. Reset it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review.
CVE-2026-64384CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: smb: client: fix change notify replay double-free A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_notify_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free.
CVE-2026-64383CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double-free in SMB2_flush() replay SMB2_flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifs_send_recv() stores a replacement response, flush_exit will free the stale response pointer a second time. Reinitialize resp_buftype and rsp_iov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.
CVE-2026-64385CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double-free in SMB2_ioctl() replay A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_ioctl_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free.
CVE-2026-64056CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Make RX SKB per-port The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both. Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead. Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped. Zero it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2026-64355. Free for 1 server.

Get started free