CVE-2026-43303
Received Received - Intake
Use-After-Free in Linux Kernel Page Allocation

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's memory management system, specifically in the handling of page structures during memory allocation and freeing.

Several subsystems use a field called page->private but do not clear it before freeing pages. When these pages are later reallocated as high-order pages and split, the tail pages retain stale page->private values.

This leads to a use-after-free condition in the swap subsystem, where the swap code assumes freshly allocated pages have page->private set to zero. Stale values cause the swap code to incorrectly process continuation lists, leading to iteration over uninitialized memory and ultimately causing a kernel crash.

The vulnerability is fixed by clearing the page->private field in the free_pages_prepare() function, ensuring all freed pages have a clean state.


How can this vulnerability impact me? :

This vulnerability can cause a kernel crash due to use-after-free errors in the swap subsystem.

Such crashes can lead to system instability, potential denial of service, and unexpected reboots, affecting the availability of systems running vulnerable Linux kernels.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a use-after-free in the swap subsystem of the Linux kernel, potentially causing system crashes with messages similar to:

  • KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107]
  • RIP: 0010:__do_sys_swapoff+0x1151/0x1860

To detect this issue on your system, monitor kernel logs for such crash messages or KASAN warnings related to swapoff operations. You can use commands like:

  • dmesg | grep -i kasan
  • journalctl -k | grep -i swapoff
  • journalctl -k | grep -i 'wild-memory-access'

Additionally, monitoring for unexpected system crashes or swap subsystem errors can indicate the presence of this vulnerability.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by clearing the page->private field in free_pages_prepare(), ensuring freed pages have a clean state.

Immediate mitigation steps include:

  • Update your Linux kernel to a version that includes the fix for this vulnerability.
  • Avoid using swapoff operations on systems running vulnerable kernel versions until patched.
  • Monitor system stability and kernel logs for related crashes or warnings.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart