Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:57.563Z",
  "pubdate": "2026-08-28T08:16:57.563Z",
  "executiveSummary": "A memory corruption vulnerability exists within the Linux kernel's per-CPU memory allocator, specifically within the pcpu_create_chunk() function.\nThe vulnerability is characterized by a heap-based buffer overflow stemming from incorrect bitmap size calculations when managing populated memory pages.\nThe flaw affects the percpu-km implementation and results in out-of-bounds memory writes when nr_units exceeds one.\nAn attacker capable of triggering per-CPU chunk creation could potentially leverage this overflow to overwrite adjacent kernel memory structures, leading to system instability, kernel panics, or potential privilege escalation.\nThe issue also disrupts global accounting metrics (pcpu_nr_empty_pop_pages), leading to inaccurate memory management state tracking within the kernel allocator.\nThis vulnerability is an architectural flaw in memory management logic that does not explicitly require network exposure but is triggered through standard system operations that utilize the per-CPU memory allocation subsystem.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper calculation of memory boundaries within pcpu_create_chunk(). In the affected versions, the variable nr_pages is derived as the product of nr_units and pcpu_unit_pages, representing the total contiguous backing allocation.\nHowever, the kernel uses this value to initialize the chunk->populated bitmap, which is intended to track page status only for a single unit (pcpu_unit_pages). When the configuration involves multiple units (nr_units > 1), the bitmap size allocated for the chunk is insufficient to accommodate the total nr_pages reported.\nConsequently, the call to pcpu_chunk_populated() performs writes that exceed the boundaries of the bitmap memory. This buffer overflow corrupts adjacent heap memory objects belonging to the kernel. Because the per-CPU allocator is a foundational component, memory corruption here can compromise the integrity of subsequent kernel allocations or data structures located in proximity to the overflowed bitmap.\nFurthermore, the vulnerability introduces an accounting error. The function pcpu_balance_free() relies on the consistency of the populated page count to manage memory reclamation; by miscalculating the populated status across units, the kernel maintains an incorrect state for pcpu_nr_empty_pop_pages. This discrepancy can lead to premature memory exhaustion or illegal state transitions in the allocator's management logic.\nThe regression was introduced in commit a63d4ac4ab609, which initially implemented the bitmap management, and was exacerbated by commit b539b87fed37f, which introduced the broken accounting mechanism. Exploitation requires an attacker to invoke code paths that trigger the creation of a multi-unit per-CPU chunk. If successful, the heap overflow allows for the modification of arbitrary kernel data, which, depending on the kernel memory layout at runtime, could be weaponized to achieve arbitrary code execution or local privilege escalation. The vulnerability persists until the fix that constrains the population logic to the chunk's actual nr_pages size is applied, ensuring that the bitmap boundary is respected even when multiple units are initialized."
}