CVE-2026-43303: mm/page_alloc: clear page->private in free_pages_prepare()
In the Linux kernel, the following vulnerability has been resolved:
mm/page_alloc: clear page->private in free_pages_prepare()
Several subsystems (slub, shmem, ttm, etc.) use page->private but don't
clear it before freeing pages. When these pages are later allocated as
high-order pages and split via split_page(), tail pages retain stale
page->private values.
This causes a use-after-free in the swap subsystem. The swap code uses
page->private to track swap count continuations, assuming freshly
allocated pages have page->private == 0. When stale values are present,
swap_count_continued() incorrectly assumes the continuation list is valid
and iterates over uninitialized page->lru containing LIST_POISON values,
causing a crash:
KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107]
RIP: 0010:__do_sys_swapoff+0x1151/0x1860
Fix this by clearing page->private in free_pages_prepare(), ensuring all
freed pages have clean state regardless of previous use.
Security readout for executives and security teams
Plain-English summary
Linux may recycle memory pages while retaining stale internal bookkeeping. A later swap operation can trust that stale data, access freed memory, and crash the kernel. The supplied CVSS score is 7.8 (high). The sources do not show active exploitation.
Executive priority
Treat this as a high-priority Linux maintenance issue, particularly on shared systems allowing local low-privilege access. Schedule prompt, tested kernel updates. Its local attack path and lack of documented active exploitation do not support treating it as an internet-wide emergency, but a kernel-level memory-safety flaw warrants timely remediation.
Technical view
Multiple subsystems can free pages without clearing page->private. If later allocated as high-order pages and split, tail pages retain stale values. swap_count_continued() may interpret them as valid continuation metadata and traverse poisoned, uninitialized page->lru data, producing a use-after-free or wild-memory access. The fix clears page->private in free_pages_prepare().
Likely exposure
The bundle lists affected Linux version entries spanning 5.18 through 7.0, but does not clearly express every range boundary. Exposure requires matching each running kernel build against its distribution's backports and the applicable stable fix commit. The CVSS vector describes a local, low-complexity attack requiring low privileges and no user interaction.
Exploitation context
CISA KEV status is false, and the supplied sources provide no evidence of active exploitation or a public exploit. The documented result is a kernel crash during swapoff under KASAN. Although CVSS scores confidentiality, integrity, and availability impacts as high, reliable impact beyond crashing is not demonstrated in the source narrative.
Researcher notes
Stale page->private survives allocator reuse and split_page() processing of tail pages. Swap continuation logic trusts the field, follows poisoned page->lru pointers, and encounters a use-after-free or wild access. The upstream correction centralizes state clearing in free_pages_prepare(). No CWE is supplied, and controlled code execution is not established.
Mitigation direction
Install a vendor-supported kernel incorporating the applicable upstream stable fix commit.
Match the fix to your kernel branch using the six cited stable commits.
If updates are unavailable, request distribution-specific guidance; the supplied sources name no workaround.
Limit unnecessary low-privilege local access until remediation; this is only temporary risk reduction.
Validation and detection
Inventory running kernel releases and package build identifiers on exposed Linux hosts.
Compare each build with its distributor advisory and the applicable cited stable commit.
After reboot, verify the running kernel package includes the fix, not merely the installed package.
Review kernel logs for swapoff crashes, KASAN reports, or the documented wild-memory-access signature.
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-2026-43303 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
7Source 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.