KernelScan.io

HIGH Introduced in 3.18

percpu-km ChunkBitmap Overflow

CVE-2026-80718

CVSS 7.8 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

KernelScan AI7.8HIGH

01

In the Linux kernel, the following vulnerability has been resolved: mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() In pcpu_create_chunk(), nr_pages is the total contiguous backing allocation, i.e., nr_units * pcpu_unit_pages, but pcpu_chunk_populated() uses it to set chunk->populated, whose size is pcpu_unit_pages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nr_units > 1, the function writes beyond chunk->populated. Fix it by using chunk->nr_pages. It also fixes the global pcpu_nr_empty_pop_pages accounting, since pcpu_balance_free() only iterates up to chunk->nr_pages. Commit a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") introduced the bitmap overflow issue. Later, commit b539b87fed37f ("percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated") added pcpu_nr_empty_pop_pages and caused the accounting issue.

02

Engine v0.6.0

Risk summary

A bitmap overflow in the percpu-km allocator writes beyond the populated bitmap when nr_units > 1, corrupting adjacent memory in the chunk structure. Any local process can trigger this by allocating percpu memory, potentially leading to privilege escalation or kernel panic.

Affectedmm/percpu-km.c (percpu memory allocator)

Vulnerability analysis

The percpu memory allocator uses a bitmap to track which pages are backed, but when creating a new chunk, it mistakenly uses the total page count across all CPU units rather than the per-unit page count. On systems with multiple CPU units, this causes a write beyond the end of the bitmap, corrupting adjacent memory and throwing off global page accounting. The fix ensures only the correctly sized per-unit page count is used when marking the bitmap. Any local process that allocates percpu memory can trigger this corruption on multi-CPU systems.

03

BranchIntroducedFixed inPatch commit
5.103.185.10.2655f43d2c1bea2
5.153.185.15.21692c43ac3c2b0
6.13.186.1.1836fc7da2a052f
6.123.186.12.103a6940b84c8c0
6.183.186.18.4432134cf9211b
6.63.186.6.15101504da375f5
7.13.187.1.85c7fc39bf19a
mainline3.187.289b1b79c3088
cip/4.193.184.19.325-cip1364cb8a4d3548a
cip/4.19-rt3.184.19.325-cip136-rt504cb8a4d3548a
cip/5.103.185.10.268-cip775f43d2c1bea2
cip/5.10-rt3.185.10.268-cip77-rt345f43d2c1bea2
cip/6.13.186.1.187-cip606fc7da2a052f
cip/6.1-rt3.186.1.189-cip61-rt326fc7da2a052f
cip/6.123.186.12.104-cip30a6940b84c8c0

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.104-cip30
cip/6.1Fixed in 6.1.187-cip60
cip/6.1-rtFixed in 6.1.189-cip61-rt32
cip/5.10Fixed in 5.10.268-cip77
cip/5.10-rtFixed in 5.10.268-cip77-rt34
cip/4.19Fixed in 4.19.325-cip136
cip/4.19-rtFixed in 4.19.325-cip136-rt50
cip/4.4Affected — no CIP fix yet (latest 4.4.302-cip115)
cip/4.4-rtAffected — no CIP fix yet (latest 4.4.302-cip115-rt63)