Cloudanix VulnDB

CVE-2026-93172

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A kernel bug could let specially crafted memory changes crash the entire system during certain hardware additions.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Missing NULL check after alloc_percpu for pgdat->per_cpu_nodestats allows offset into uninitialized per-CPU area, producing a NULL pointer dereference during hotplug memory initialization.

Why it matters to the business

Systems performing memory hot-add operations may experience kernel crashes or unexpected node online failures, disrupting workloads that rely on dynamic memory scaling in virtualized or large-memory environments.

How an attack unfolds

An attacker with local access triggers memory hotplug paths while simultaneously inducing percpu allocation pressure so that pgdat->per_cpu_nodestats remains NULL; subsequent offset access then dereferences the pointer and crashes the kernel.

How to fix it

Apply the upstream fix that propagates -ENOMEM from hotadd_init_pgdat, ensures per_cpu_nodestats falls back to boot_nodestats, and prevents the node from being marked online on failure. Reboot after installing the patched kernel.

How to confirm the fix worked

Confirm the patched kernel contains the updated free_area_init_core_hotplug logic that checks alloc_percpu return value; attempt a controlled memory hot-add under memory pressure and verify the operation returns -ENOMEM rather than dereferencing NULL.

Typical attack path

  1. Obtain local code execution on target system
  2. Force repeated memory hot-add operations via /sys/devices/system/memory or driver interfaces
  3. Concurrently exhaust percpu memory to cause alloc_percpu failure
  4. Trigger the unhandled NULL dereference in free_area_init_core_hotplug

How to detect it

Search kernel logs for oops or panic messages referencing per_cpu_nodestats, free_area_init_core_hotplug, or hotadd_init_pgdat around the time of memory hotplug events; examine dmesg and journalctl for allocation failure paths that precede a NULL dereference.

What your security team should do

  • Prioritize kernel updates on systems that perform memory hotplug (cloud hosts, NUMA servers)
  • Monitor for kernel oops involving per_cpu_nodestats or free_area_init_core_hotplug
  • Limit unprivileged access to memory hotplug sysfs interfaces until patched

The record

In the Linux kernel, the following vulnerability has been resolved: mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation

Affected packages

Ecosystem Package Introduced Fixed