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.
No analysis available yet.
No remediation available yet.
Tracking
Sign in to view the affected projects.
| Source | ID | Title |
|---|---|---|
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 |
USN-7699-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7699-2 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7721-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8028-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8028-2 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-8031-1 | Linux kernel (GCP) vulnerabilities |
Ubuntu USN |
USN-8028-3 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-8028-4 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-8028-5 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8031-2 | Linux kernel (GCP FIPS) vulnerabilities |
Ubuntu USN |
USN-8028-6 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-8031-3 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8052-1 | Linux kernel (Low Latency) vulnerabilities |
Ubuntu USN |
USN-8028-7 | Linux kernel (Low Latency NVIDIA) vulnerabilities |
Ubuntu USN |
USN-8028-8 | Linux kernel (IBM) vulnerabilities |
Ubuntu USN |
USN-8052-2 | Linux kernel (Xilinx) vulnerabilities |
Ubuntu USN |
USN-8074-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-8074-2 | Linux kernel (Azure FIPS) vulnerabilities |
Ubuntu USN |
USN-8126-1 | Linux kernel (Azure) vulnerabilities |
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
|
cvssV3_1
|
Fri, 20 Jun 2025 23:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
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 |
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-06-18T09:28:19.358Z
Reserved: 2025-04-16T04:51:23.977Z
Link: CVE-2025-38008
No data.
Status : Analyzed
Published: 2025-06-18T10:15:32.037
Modified: 2025-11-17T12:56:52.697
Link: CVE-2025-38008
OpenCVE Enrichment
Updated: 2025-06-23T08:53:47Z
EUVD
Ubuntu USN