CVE-2026-80718: mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk()
In the Linux kernel, the following vulnerability has been resolved:
mm/percpu-km: fix bitmap overflow and accounting in pcpucreatechunk()
In pcpucreatechunk(), nrpages is the total contiguous backing allocation, i.e., nrunits pcpuunitpages, but pcpuchunkpopulated() uses it to set chunk->populated, whose size is pcpuunitpages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nrunits > 1, the function writes beyond chunk->populated. Fix it by using chunk->nrpages.
It also fixes the global pcpunremptypoppages accounting, since pcpubalancefree() only iterates up to chunk->nrpages.
Commit a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") introduced the bitmap overflow issue. Later, commit b539b87fed37f ("percpu: implmeent pcpunremptypoppages and chunk->nrpopulated") added pcpunremptypoppages and caused the accounting issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch a63d4ac4ab609 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch b539b87fed37f
Event History
Frequently Asked Questions
What kernel code path is affected?
The issue is in the Linux kernel percpu-km allocator, specifically pcpu_create_chunk(). It occurs when the allocator initializes the chunk->populated bitmap using the total backing allocation page count rather than the per-unit page count.
When does the bitmap overflow occur?
The overflow occurs when a percpu chunk has more than one unit (nr_units > 1). In that case, using nr_pages causes writes beyond the chunk->populated bitmap, which is sized for pcpu_unit_pages.
What is the impact besides the out-of-bounds bitmap write?
The affected logic also produces incorrect global pcpu_nr_empty_pop_pages accounting. The description notes that pcpu_balance_free() iterates only up to chunk->nr_pages, so the prior accounting does not match the populated-page tracking.
How can I determine whether my kernel contains the vulnerable logic?
Review whether the kernel includes commit a63d4ac4ab609, which introduced the bitmap overflow, and commit b539b87fed37f, which added the affected empty populated-page accounting. The supplied stable kernel references identify fixes for the issue.