CVE-2025-40199: page_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches
In the Linux kernel, the following vulnerability has been resolved:
page_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches
Helge reported that the introduction of PP_MAGIC_MASK let to crashes on
boot on his 32-bit parisc machine. The cause of this is the mask is set
too wide, so the page_pool_page_is_pp() incurs false positives which
crashes the machine.
Just disabling the check in page_pool_is_pp() will lead to the page_pool
code itself malfunctioning; so instead of doing this, this patch changes
the define for PP_DMA_INDEX_BITS to avoid mistaking arbitrary kernel
pointers for page_pool-tagged pages.
The fix relies on the kernel pointers that alias with the pp_magic field
always being above PAGE_OFFSET. With this assumption, we can use the
lowest bit of the value of PAGE_OFFSET as the upper bound of the
PP_DMA_INDEX_MASK, which should avoid the false positives.
Because we cannot rely on PAGE_OFFSET always being a compile-time
constant, nor on it always being >0, we fall back to disabling the
dma_index storage when there are not enough bits available. This leaves
us in the situation we were in before the patch in the Fixes tag, but
only on a subset of architecture configurations. This seems to be the
best we can do until the transition to page types in complete for
page_pool pages.
v2:
- Make sure there's at least 8 bits available and that the PAGE_OFFSET
bit calculation doesn't wrap
Security readout for executives and security teams
Plain-English summary
A Linux kernel page-pool error can mistake ordinary memory pointers for specially tagged pages, causing crashes during startup on some 32-bit architectures. A 32-bit parisc system is the confirmed example. This creates a serious availability risk for affected systems, but the supplied evidence does not establish broad architectural impact or malicious exploitation.
Executive priority
Treat this as a focused high-priority reliability issue, not evidence of an active campaign. Expedite assessment for business-critical 32-bit Linux systems and recovery-sensitive appliances. For predominantly 64-bit fleets, first establish whether any affected architecture configurations exist before escalating to emergency-wide remediation.
Technical view
PP_MAGIC_MASK allocated too many bits, allowing page_pool_page_is_pp() to return false positives for arbitrary kernel pointers. The correction bounds PP_DMA_INDEX_MASK using PAGE_OFFSET and disables dma_index storage when fewer than eight safe bits are available. This prevents pointer misclassification while preserving page-pool operation where the index cannot be safely stored.
Likely exposure
Exposure appears concentrated in Linux kernels containing the faulty page-pool change on certain 32-bit architecture configurations. The supplied affected-version data is ambiguous and should not be treated as complete release ranges. Prioritize 32-bit parisc and other 32-bit systems, then confirm distribution-specific backports against the referenced stable-kernel fixes.
Exploitation context
The documented failure is a boot crash reported on 32-bit parisc. The CVSS vector describes a local, low-privilege attack surface, but the supplied technical description does not explain a reproducible attacker-controlled path. The record is not marked KEV, and no cited source establishes active exploitation.
Researcher notes
The evidence supports a pointer-tagging false-positive and resulting kernel crash. It does not establish which architectures beyond the reported 32-bit parisc case are practically affected, nor demonstrate confidentiality or integrity impact despite the supplied CVSS vector. Version entries lack clear range semantics, so commit-level and vendor-backport analysis is essential.
Mitigation direction
Install a vendor-supported kernel containing the applicable referenced stable fix.
Check distribution advisories for backported fixes rather than relying solely on release numbers.
Prioritize affected 32-bit systems where an unexpected reboot could cause material disruption.
Test corrected kernels on representative 32-bit hardware before production rollout.
Validation and detection
Inventory kernel versions and architectures, emphasizing 32-bit parisc and other 32-bit deployments.
Compare vendor kernel changelogs against the three referenced stable-kernel commits.
Confirm systems boot successfully after updating under representative page-pool workloads.
Monitor boot and kernel logs for page-pool faults or unexpected crashes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-40199 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.