---
id: CVE-2026-98149
title: |-
  In the Linux kernel, the following vulnerability has been resolved:

  bpf: Fix percpu map update indexing with sparse CPU IDs

  Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU
  or BPF_F_ALL_CPUS use a value buffer whos…
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  bpf: Fix percpu map update indexing with sparse CPU IDs

  Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU
  or BPF_F_ALL_CPUS use a value buffer whos…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 8eb76cb03f0f6c2bd7b15cf45dcffcd6bd07a360 <
    c16c62c91e5d6737a9fbb0a541b8b34610470a2b
  - >-
    Linux >= 8eb76cb03f0f6c2bd7b15cf45dcffcd6bd07a360 <
    75b0a6db4300e4c2c9e97a0848deaa7acfb42fb7
  - Linux 7.0
published: '2026-09-25'
updated: '2026-09-25'
sourceUpdated: '2026-09-25T11:17:46.473'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-98149'
references:
  - url: 'https://git.kernel.org/stable/c/75b0a6db4300e4c2c9e97a0848deaa7acfb42fb7'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/c16c62c91e5d6737a9fbb0a541b8b34610470a2b'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-25T11:06:38.806Z'
---

## Overview

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix percpu map update indexing with sparse CPU IDs

Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU
or BPF_F_ALL_CPUS use a value buffer whose per-CPU slots are packed in
possible-CPU order. The buffer is sized as:

  round_up(value_size, 8) * num_possible_cpus()

The update paths iterate over possible CPUs, but use the logical CPU ID
to calculate the source offset:

  value + size * cpu

This only works when possible CPU IDs are contiguous starting at zero.

For example, with a possible CPU mask of 0,2-3, the buffer contains
three slots corresponding to CPUs 0, 2, and 3. CPU2 is therefore
expected to use slot 1 and CPU3 slot 2. Instead, the current code uses
slots 2 and 3 respectively, causing incorrect per-CPU values and an
out-of-bounds read from the update buffer for CPU3.

The corresponding lookup paths already use a dense offset while
iterating over possible CPUs. Do the same for the array, hash, and
cgroup storage update paths, advancing the source offset once for each
possible CPU. BPF_F_ALL_CPUS continues to use the same value for every
CPU.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.