---
id: "CVE-2026-98588"
kind: "vulnerability"
aliases: ["CVE-2026-98588"]
title: "Linux kernel: oversized SOCKMAP size lets a BPF map free write out of bounds"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["bpf", "infrastructure", "linux-kernel", "self-hosted"]
not_affected_if: ["kernel-with-fix", "unprivileged-bpf-disabled"]
published_at: "2026-10-18T16:17:11+00:00"
first_seen_at: "2026-10-23T21:57:15+00:00"
updated_at: "2026-10-25T05:22:59+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98588", "first_seen_at": "2026-10-23T21:57:15+00:00"}]
---

# Linux kernel: oversized SOCKMAP size lets a BPF map free write out of bounds

Creating 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, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `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.
- Check whether unprivileged BPF is allowed with `sysctl kernel.unprivileged_bpf_disabled`; unknown whether this is the only requirement to trigger it.

## Fix

- Update the Linux kernel to a stable release that includes the sock_map_alloc max_entries > INT_MAX check (exact version unknown from the sources).
- Until patched, consider restricting unprivileged BPF with `sysctl -w kernel.unprivileged_bpf_disabled=2`.

## Timeline

- 2026-10-23T21:57:15+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98588

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_