CVE-2026-98588

What it actually does

sock_map_alloc accepts max_entries up to UINT_MAX without enforcing INT_MAX bound; sock_map_free then iterates with a signed int, causing wrap to INT_MIN, sign-extension, and an out-of-bounds xchg write far below the sks[] allocation during map destruction.

Why it matters to the business

Systems using BPF sockmaps can experience kernel crashes or memory corruption when such maps are created and later freed, leading to denial of service or potential privilege escalation on large-memory hosts.

How an attack unfolds

An attacker invokes the BPF map_create syscall to allocate a SOCKMAP with max_entries set to 0xffffffff; subsequent close or deferred free path reaches sock_map_free, where the signed iterator overflows and performs an uncontrolled write that either faults or corrupts unrelated kernel memory.

How to fix it

Apply the upstream fix that rejects max_entries > INT_MAX inside sock_map_alloc; rebuild and deploy kernels containing the corrected bpf, sockmap logic; avoid creating sockmaps with entries near UINT_MAX until patched.

How to confirm the fix worked

Attempt BPF map creation with max_entries=0xffffffff on a test system and confirm the operation is now rejected with -EINVAL; verify absence of the sign-extension path in sock_map_free disassembly; monitor for the specific KASAN oops signature on unpatched kernels.

Typical attack path

1. Invoke bpf() syscall with BPF_MAP_CREATE for SOCKMAP type and max_entries=0xffffffff
2. Trigger map destruction via close() or process exit
3. sock_map_free iterates with signed int that wraps, producing negative offset into sks[]
4. xchg() write lands at attacker-controlled or unmapped address causing oops or corruption

How to detect it

Search kernel logs for 'BUG: unable to handle page fault' near kasan_check_range and sock_map_free; inspect BPF audit records or syscall traces for map_create operations requesting max_entries values exceeding INT_MAX; correlate vmcore analysis showing stab->map.max_entries == 0xffffffff.

• kasan_check_range+0x107/0x190
• sock_map_free+0x93/0x190
• max_entries == 0xffffffff
• sks + (s64)INT_MIN * 8

What your security team should do

• Prioritize kernel updates containing the sock_map_alloc bounds check within the next maintenance window
• Audit any production workloads that create large BPF sockmaps and reduce entry counts below INT_MAX
• Enable CONFIG_KASAN_VMALLOC on test kernels to surface the bug during validation
• Add runtime checks or seccomp filters that block oversized map creation until patches are deployed