Live › vulnerability › CVE-2026-98588
Go to dashboardCreating a SOCKMAP with max_entries above INT_MAX makes the kernel's free routine loop with a wrapped signed counter, writing far outside the allocated array. The sources do not say whether this gives an attacker code execution or only a crash.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Hosts running a Linux kernel without the upstream fix that can create BPF SOCKMAP maps, which includes any system where a local process can use the bpf() syscall. The sources reproduce it on a KASAN 6.6-based kernel and upstream v7.3-rc2, and say it needs large-memory hosts for the 32 GiB allocation to succeed. Systems with unprivileged BPF disabled or restricted are likely less exposed, but the sources do not confirm this.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel builds in the kernel.org stable changelog for the upstream commit that adds the max_entries > INT_MAX check in sock_map_alloc.sysctl kernel.unprivileged_bpf_disabled; unknown whether this is the only requirement to trigger it.sysctl -w kernel.unprivileged_bpf_disabled=2.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Reject max_entries > INT_MAX in sock_map_alloc
sock_map_alloc() only rejects max_entries == 0 and otherwise allows any u32 value. sock_map_free() then walks the sks[] array with a signed int iterator:
int i;
for (i = 0; i < stab->map.max_entries; i++)
struct sock **psk = &stab->sks[i];
When a SOCKMAP is created with max_entries = 0xffffffff (UINT_MAX), the allocation of 32 GiB can succeed on large-memory hosts. During free the counter reaches 0x80000000, wraps to INT_MIN, is sign-extended by movslq and turned into a ~16 GiB negative offset from stab->sks, pointing far below the allocation.
The faulting access is an xchg() write in sock_map_free(). Without KASAN, the same out-of-bounds write can fault on an unmapped vmalloc page or corrupt an unrelated allocation if that vmalloc address is populated. On a KASAN kernel with CONFIG_KASAN_VMALLOC=y, the shadow check for that address hits an unmapped shadow page and oopses first:
BUG: unable to handle page fault for address: fffff521b59c5a00 RIP: 0010:kasan_check_range+0x107/0x190 Call Trace: sock_map_free+0x93/0x190 map_create+0x68d/0xb30 __sys_bpf+0x21e/0x2e70
Vmcore confirmed stab->map.max_entries == 0xffffffff, stab->sks == 0xffffc911ace2d000, and the faulting address sks + (s64)INT_MIN * 8 exactly at 0xffffc90dace2d000. The same buggy path is reached on the normal close()/bpf_map_free_deferred() path whenever such a map is destroyed.
sock_map_alloc() used to bound its allocation size through bpf_map_charge_init(), but the bound was dropped when rlimit-based memory accounting was removed. Reject max_entries > INT_MAX at creation time so the signed iterator in sock_map_free() never sees a value that would overflow.
Triggered by syzkaller and reproduced on both a 6.6-based KASAN kernel and the upstream v7.3-rc2 kernel.
This page as .md · .json · in your agent: get_signal("CVE-2026-98588")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.