Bug 2468091 (CVE-2026-43303)

Summary: CVE-2026-43303 kernel: mm/page_alloc: clear page->private in free_pages_prepare()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's memory management subsystem. When pages are freed, the page->private field is not properly cleared. If these pages are later reallocated as high-order pages and split, the tail pages can retain stale page->private values. This can lead to a use-after-free vulnerability in the swap subsystem, where incorrect assumptions about the page->private value can cause the system to crash.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-05-08 14:04:02 UTC
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.

Comment 5 errata-xmlrpc 2026-05-28 01:20:07 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:21557 https://access.redhat.com/errata/RHSA-2026:21557

Comment 6 errata-xmlrpc 2026-05-28 01:24:11 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:21556 https://access.redhat.com/errata/RHSA-2026:21556

Comment 7 errata-xmlrpc 2026-06-17 01:14:03 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions

Via RHSA-2026:26462 https://access.redhat.com/errata/RHSA-2026:26462

Comment 8 errata-xmlrpc 2026-06-17 06:33:38 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions

Via RHSA-2026:26515 https://access.redhat.com/errata/RHSA-2026:26515

Comment 10 errata-xmlrpc 2026-06-22 05:56:01 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.6 Extended Update Support

Via RHSA-2026:27708 https://access.redhat.com/errata/RHSA-2026:27708

Comment 11 errata-xmlrpc 2026-06-22 06:02:09 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions

Via RHSA-2026:27735 https://access.redhat.com/errata/RHSA-2026:27735

Comment 12 errata-xmlrpc 2026-06-29 19:23:56 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10.0 Extended Update Support

Via RHSA-2026:33215 https://access.redhat.com/errata/RHSA-2026:33215