GHSA-79FG-R6V6-PRP7
Vulnerability from github – Published: 2025-11-13 00:30 – Updated: 2025-11-13 00:30In 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
{
"affected": [],
"aliases": [
"CVE-2025-40199"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-12T22:15:47Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches\n\nHelge reported that the introduction of PP_MAGIC_MASK let to crashes on\nboot on his 32-bit parisc machine. The cause of this is the mask is set\ntoo wide, so the page_pool_page_is_pp() incurs false positives which\ncrashes the machine.\n\nJust disabling the check in page_pool_is_pp() will lead to the page_pool\ncode itself malfunctioning; so instead of doing this, this patch changes\nthe define for PP_DMA_INDEX_BITS to avoid mistaking arbitrary kernel\npointers for page_pool-tagged pages.\n\nThe fix relies on the kernel pointers that alias with the pp_magic field\nalways being above PAGE_OFFSET. With this assumption, we can use the\nlowest bit of the value of PAGE_OFFSET as the upper bound of the\nPP_DMA_INDEX_MASK, which should avoid the false positives.\n\nBecause we cannot rely on PAGE_OFFSET always being a compile-time\nconstant, nor on it always being \u003e0, we fall back to disabling the\ndma_index storage when there are not enough bits available. This leaves\nus in the situation we were in before the patch in the Fixes tag, but\nonly on a subset of architecture configurations. This seems to be the\nbest we can do until the transition to page types in complete for\npage_pool pages.\n\nv2:\n- Make sure there\u0027s at least 8 bits available and that the PAGE_OFFSET\n bit calculation doesn\u0027t wrap",
"id": "GHSA-79fg-r6v6-prp7",
"modified": "2025-11-13T00:30:18Z",
"published": "2025-11-13T00:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40199"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/15b8a5b4cdc16e9a8bb2a548e12a0fd92997605a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95920c2ed02bde551ab654e9749c2ca7bc3100e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f62934cea32c8f7b11b747975d69bf5afe4264cf"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.