CVE-2026-43303

What it actually does

This is a Linux kernel memory-management use-after-free/state-reuse flaw. Some kernel subsystems store metadata in page->private and free pages without clearing that field. If those pages are later reallocated as high-order pages and split, tail pages can retain stale page->private values. The swap subsystem expects newly allocated pages to have page->private == 0; stale values can make swap code treat uninitialized structures as valid continuation metadata and traverse poisoned list pointers. The observed failure path is a kernel crash in swapoff processing, and because the bug occurs in kernel memory-management code, successful exploitation could potentially affect confidentiality, integrity, and availability depending on kernel configuration, memory layout, and exploit reliability.

Why it matters to the business

An attacker with local access to a vulnerable Linux system could cause a kernel crash and service outage, and in a worst case may be able to turn the kernel memory corruption into privilege escalation or unauthorized access to sensitive data. The issue is not listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no public exploit maturity reported, so broad internet-scale exploitation is not currently indicated; however, Linux kernel flaws still matter for shared servers, multi-user systems, container hosts, virtualization platforms, and high-availability infrastructure because local compromise or denial of service can have wide operational impact.

How an attack unfolds

An attacker first needs the ability to run code locally as an unprivileged or low-privileged user on a vulnerable Linux system. They then attempt to influence kernel page allocation patterns so pages previously used by subsystems that set page->private are freed without that field being cleared. Later, the attacker triggers allocations that produce high-order pages which are split, leaving stale page->private values on tail pages. By exercising swap-related functionality, particularly paths that inspect swap count continuation metadata, the kernel may interpret the stale page->private value as a valid continuation list. The swap code can then traverse uninitialized or poisoned list pointers, leading to a kernel fault such as a crash in __do_sys_swapoff. Public exploitation is not known from the provided data, so practical weaponization beyond denial of service should be treated as possible but unconfirmed.

How to fix it

Upgrade to a Linux kernel version, distribution kernel, or vendor advisory build that includes the fix to clear page->private in free_pages_prepare(). No exact fixed package versions were provided, so use the relevant Linux distribution or appliance vendor security advisory for the affected kernel branch. Prioritize systems that allow local shell access, run untrusted workloads, host containers or virtual machines, use swap, or provide shared multi-user services. If immediate patching is not possible, reduce exposure by limiting local interactive access, restricting untrusted code execution, hardening container isolation, disabling or tightly controlling swap-management privileges, and applying standard kernel hardening options where available. Mitigations should be considered temporary because the vulnerable state exists in core kernel memory-management code.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is a vendor-fixed build containing the page allocator change that clears page->private in free_pages_prepare(). Reboot into the fixed kernel after installation; installing a kernel package without rebooting does not remove exposure from the running kernel. Validate with uname -a and distribution package metadata such as rpm -q --changelog kernel, dpkg -l linux-image-*, apt changelog, vendor errata, or appliance firmware release notes. Review kernel build notes or source patches for references to mm/page_alloc, free_pages_prepare(), and clearing page->private. Where safe and appropriate, confirm that no vulnerable kernel remains bootable as the default entry in the bootloader. Do not rely on absence of crashes as proof of remediation, because exploitation requires specific memory state and trigger conditions.

Typical attack path

1. Obtain local code execution on a vulnerable Linux host as a low-privileged user.
2. Create memory pressure or otherwise exercise kernel subsystems that use page->private, such as slab-related, shmem, graphics memory, or other page-management paths.
3. Cause affected pages to be freed while retaining stale page->private state.
4. Trigger high-order page allocation and splitting so stale page->private values remain on tail pages.
5. Exercise swap-related operations that cause the swap subsystem to evaluate page->private as swap count continuation metadata.
6. Induce kernel traversal of invalid or poisoned list pointers, causing a crash or potentially exploitable kernel memory corruption.

How to detect it

Look for evidence of kernel faults or repeated system crashes associated with swap operations and memory-management list corruption. Primary log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, crash dump directories, kdump/vmcore repositories, auditd logs, sudo logs, shell history, and endpoint telemetry showing process execution around swap-management commands. Search for KASAN reports mentioning wild-memory-access, LIST_POISON, __do_sys_swapoff, swapoff, swap_count_continued, page->private, page_alloc, or lru list corruption. Correlate crashes with local users executing memory-pressure workloads, container workloads, fuzzers, swapoff/swapon commands, or scripts that manipulate swap. Because no public exploit indicators are provided and exploitation is local, detection should focus on behavioral correlation: unexplained kernel panics, repeated swapoff-triggered crashes, suspicious local code execution shortly before the crash, and attempts to run kernel fuzzing or memory-stress tooling. Absence of these artifacts does not prove the vulnerability was not exercised, especially if persistent kernel logs or crash dumps are not retained.

• KASAN: maybe wild-memory-access
• __do_sys_swapoff
• swap_count_continued
• LIST_POISON
• 0xdead000000000100
• 0xdead000000000107
• page->private
• free_pages_prepare
• mm/page_alloc
• kernel BUG
• Unable to handle kernel paging request
• general protection fault
• Oops:
• Kernel panic
• swapoff

What your security team should do

• Inventory Linux systems and identify those running affected kernel branches, prioritizing multi-user servers, container hosts, virtualization hosts, build systems, and systems where untrusted users can execute code.
• Apply vendor kernel updates that include the free_pages_prepare() page->private clearing fix, then reboot to activate the fixed kernel.
• Treat this as a local kernel privilege-escalation and denial-of-service risk despite low EPSS, because local footholds on shared infrastructure can become high-impact incidents.
• Restrict local shell access and untrusted workload execution until patching is complete, especially on shared compute and container platforms.
• Monitor kernel logs for swapoff-related crashes, KASAN reports, LIST_POISON references, and faults in __do_sys_swapoff or swap_count_continued.
• If suspicious crashes are observed, preserve kernel logs, crash dumps, vmcore files, audit logs, and recent process execution history for forensic review.
• Ensure crash dump collection is enabled on critical Linux systems so future kernel faults can be investigated.
• Remove or deprioritize old vulnerable kernels from bootloader defaults after confirming operational stability on the fixed kernel.