GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sockmap: integer overflow in bpf_msg_push_data allocation leads to out-of-bounds memcpy

CVSS 8.4CVE-2026-64548Kernel, userspace & hypervisorcurated

Impact

In the copy fallback path taken when the scatterlist ring is full, bpf_msg_push_data() computes copy + len in 32-bit arithmetic for the page allocation size. Because len arrives from BPF as ARG_ANYTHING, a crafted value wraps the sum to a small number, producing an undersized allocation followed by an out-of-bounds memcpy - the reporter's KASAN trace shows a page fault inside __asan_memcpy from the tcp_bpf_sendmsg path. That is heap corruption in the host kernel reachable from the socket send path of a process whose socket has a sockmap program attached. On GPU nodes running a BPF-based datapath, anyone who can attach such a program turns this into a host kernel compromise or panic, and the node must be drained to recover.

Who can reach it

Local: requires the ability to load and attach a BPF sockmap/sk_msg program (CAP_BPF plus CAP_NET_ADMIN, or a permissive unprivileged-BPF setting), then drive sendmsg traffic through the socket. Distinct from the fragment-offset bug in CVE-2026-63926 - same function, different code path and different fix.

What to do

Apply the stable kernel update that adds the overflow check before the allocation (five stable branches carry the fix; see the git.kernel.org commits). Reboot each node after patching, or livepatch if your vendor offers it for this commit. Meanwhile confirm that unprivileged BPF is disabled and that tenant pods do not hold CAP_BPF.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.