Buffer Underflow Affecting kernel-64k-debug-devel package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS10-KERNEL64KDEBUGDEVEL-21273265
- published20 Oct 2026
- disclosed18 Oct 2026
Introduced: 18 Oct 2026
NewCVE-2026-98588 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-64k-debug-devel.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-debug-devel package and not the kernel-64k-debug-devel package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
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.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2555024
- https://access.redhat.com/security/cve/CVE-2026-98588
- https://git.kernel.org/stable/c/814a81c842bd88f6bd8a4ce550d560df071a5d03
- https://git.kernel.org/stable/c/909f761868fda329dc69130ef9eb5b5795bcdf00
- https://git.kernel.org/stable/c/ba7d627dbc67d62df2fa66d7b41e743c3ace0ec8
- https://git.kernel.org/stable/c/c56191af3a578b9cc265fa3bd5fc0752c59c1781
- https://git.kernel.org/stable/c/cc70972ddbf0e3398f2f32624d31db78594d50d8
- https://git.kernel.org/stable/c/cea597519b9ca6d691c98d92460ead8ece2a07af
- https://git.kernel.org/stable/c/f4a73f49e256bd835368504462be3b57b03febff