In the Linux kernel, the following vulnerability has been resolved:

mm/page_alloc: fix race condition in unaccepted memory handling

The page allocator tracks the number of zones that have unaccepted memory
using static_branch_enc/dec() and uses that static branch in hot paths to
determine if it needs to deal with unaccepted memory.

Borislav and Thomas pointed out that the tracking is racy: operations on
static_branch are not serialized against adding/removing unaccepted pages
to/from the zone.

Sanity checks inside static_branch machinery detects it:

WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0

The comment around the WARN() explains the problem:

/*
* Warn about the '-1' case though; since that means a
* decrement is concurrent with a first (0->1) increment. IOW
* people are trying to disable something that wasn't yet fully
* enabled. This suggests an ordering problem on the user side.
*/

The effect of this static_branch optimization is only visible on
microbenchmark.

Instead of adding more complexity around it, remove it altogether.

Project Subscriptions

Vendors Products
Linux Kernel Subscribe
Advisories
Source ID Title
EUVD EUVD EUVD-2025-27861 In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix race condition in unaccepted memory handling The page allocator tracks the number of zones that have unaccepted memory using static_branch_enc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory. Borislav and Thomas pointed out that the tracking is racy: operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone. Sanity checks inside static_branch machinery detects it: WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0 The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */ The effect of this static_branch optimization is only visible on microbenchmark. Instead of adding more complexity around it, remove it altogether.
Ubuntu USN Ubuntu USN USN-7699-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7699-2 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-7721-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-2 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8031-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-3 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-4 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-5 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8031-2 Linux kernel (GCP FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-6 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-8031-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8052-1 Linux kernel (Low Latency) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-7 Linux kernel (Low Latency NVIDIA) vulnerabilities
Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Mon, 17 Nov 2025 13:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc6:*:*:*:*:*:*
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}


Fri, 20 Jun 2025 23:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Wed, 18 Jun 2025 09:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix race condition in unaccepted memory handling The page allocator tracks the number of zones that have unaccepted memory using static_branch_enc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory. Borislav and Thomas pointed out that the tracking is racy: operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone. Sanity checks inside static_branch machinery detects it: WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0 The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */ The effect of this static_branch optimization is only visible on microbenchmark. Instead of adding more complexity around it, remove it altogether.
Title mm/page_alloc: fix race condition in unaccepted memory handling
References

Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2025-06-18T09:28:19.358Z

Reserved: 2025-04-16T04:51:23.977Z

Link: CVE-2025-38008

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2025-06-18T10:15:32.037

Modified: 2025-11-17T12:56:52.697

Link: CVE-2025-38008

cve-icon Redhat

Severity : Moderate

Publid Date: 2025-06-18T00:00:00Z

Links: CVE-2025-38008 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2025-06-23T08:53:47Z

Weaknesses