CVE-2026-98588 in Linux
Summary
by MITRE • 10/18/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel contains an integer overflow vulnerability within the BPF sockmap implementation, specifically in the allocation logic for socket maps. The function sock_map_alloc() is responsible for initializing these data structures but historically only validated that the requested max_entries value was not zero. This insufficient validation allowed userspace to request a map size of UINT_MAX, which corresponds to 0xffffffff or approximately four billion entries. On systems with sufficient physical memory and vmalloc space, this allocation can succeed, resulting in an attempt to reserve thirty-two gigabytes of kernel memory for the underlying array of socket pointers. While such large allocations are rare under normal usage patterns, they represent a significant resource consumption vector that can lead to system instability or denial of service if not properly constrained by security controls.
The critical technical flaw manifests during the deallocation phase in sock_map_free(). This function iterates over the allocated array using a signed integer variable i as the loop counter. When max_entries is set to UINT_MAX, the iteration proceeds normally until the counter reaches 0x80000000. At this point, incrementing the signed int causes it to wrap around to INT_MIN due to standard two's complement arithmetic rules. The subsequent use of movslq sign-extends this negative value into a sixty-four-bit register, creating a large negative offset relative to the base address of the sks array. This calculation results in an out-of-bounds memory access that points far below the allocated buffer region, specifically targeting unmapped or unrelated kernel memory regions rather than within the intended data structure boundaries.
The operational impact of this vulnerability is severe and depends heavily on whether Kernel Address Sanitizer (KASAN) is enabled with vmalloc support. In a standard production environment without KASAN, the out-of-bounds write operation executed via xchg() may fault if it targets an unmapped virtual memory page, causing a kernel panic or oops that crashes the system. However, if the calculated address happens to fall within a populated region of vmalloc space belonging to another allocation, the write can corrupt unrelated data structures in the kernel heap. This type of out-of-bounds write is particularly dangerous as it bypasses standard bounds checking mechanisms and can lead to arbitrary code execution or privilege escalation depending on what memory contents are overwritten. When KASAN with CONFIG_KASAN_VMALLOC=y is active, the vulnerability triggers an immediate fault because the shadow memory check detects access to unmapped pages before any corruption occurs, resulting in a predictable kernel oops that aids in detection but does not prevent the underlying logic error from existing.
This issue was identified and reproduced by syzkaller on both Linux version 6.6 with KASAN enabled and upstream v7.3-rc2 kernels. The root cause traces back to changes in memory accounting policies where rlimit-based limits were removed, inadvertently dropping a previous bound check that limited allocation sizes through bpf_map_charge_init(). Without this safeguard, the kernel relies solely on application-level validation which was incomplete for signed integer operations used later in the lifecycle of the map object. The vulnerability affects both explicit destruction paths and deferred cleanup routines triggered by close() or bpf_map_free_deferred(), ensuring that any sockmap created with an excessively large max_entries value will eventually trigger this flaw upon termination.
To mitigate this risk, developers have implemented a fix that rejects any request for max_entries greater than INT_MAX during the creation phase of the sock map. This validation ensures that the signed integer iterator in sock_map_free() never encounters values that would cause arithmetic overflow and subsequent out-of-bounds access. From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound, as well as CWE-787 Out-of-bounds Write, reflecting the fundamental logic error in type handling and memory safety violations. In terms of attack vectors, it relates to ATT&CK technique T1496 Resource Hijacking due to potential denial of service via resource exhaustion, although the primary security concern remains the out-of-bounds write capability which could be leveraged for further exploitation if adjacent kernel structures are targeted effectively. System administrators should ensure their kernels are updated with this patch and consider implementing strict eBPF program verification policies to limit the complexity and size of maps that unprivileged users can create, thereby reducing the attack surface for such integer overflow exploits in production environments.