CVE-2026-64477

What it actually does

This flaw is an out-of-bounds memory access in the Linux kernel x86 resctrl subsystem during CPU offlining on systems using Sub-NUMA Clustering (SNC). When the last CPU in a resctrl monitoring domain is taken offline, the domain CPU mask can become empty. The resctrl limbo handler may still attempt to read RMID monitoring state and derive a NUMA node from a non-existent CPU, causing cpu_to_node() to be called with an invalid CPU identifier. The likely impact is kernel instability, crash, or denial of service; depending on kernel build, memory layout, and hardening, out-of-bounds kernel access may also present broader memory-corruption risk. Practical exploitation appears constrained because triggering CPU hotplug/offline operations generally requires elevated local privileges.

Why it matters to the business

Affected Linux systems with Intel resctrl/RMID monitoring and SNC enabled may be vulnerable to crashes or instability when CPUs are offlined, whether through administrative operations, automation, maintenance, or a privileged local attacker. The main operational risk is denial of service on compute hosts, virtualization hosts, high-performance computing nodes, and performance-isolated workloads that rely on CPU hotplug or resctrl monitoring. The current public exploitation signal is low: EPSS is very low, no public exploit maturity is indicated, and it is not listed in CISA KEV or known ransomware use; however, kernel crash bugs can still be high-impact in availability-sensitive environments.

How an attack unfolds

An attacker would first need local access with sufficient privileges to influence CPU hotplug/offline behavior or an adjacent management path that can offline CPUs. The target system must be using the affected Linux kernel code path, have x86 resctrl monitoring active, and run on hardware/configuration where SNC affects RMID-to-NUMA mapping. The attacker or triggering workflow causes a monitoring domain to lose its last online CPU while there are busy RMIDs tracked by the resctrl limbo handler. During domain teardown, the vulnerable kernel path attempts to read RMID event state even though the domain is being forcibly released. Because the CPU mask is empty, the kernel derives a NUMA node using an invalid CPU index, causing an out-of-bounds access. In most realistic scenarios this results in a kernel Oops, panic, host reboot, or service interruption rather than remote code execution.

How to fix it

Apply the vendor-provided Linux kernel update that includes the resctrl fix. Because no exact fixed package versions were provided, use distribution advisories from the relevant Linux vendor and update to the first kernel build that backports the patch for the x86 resctrl CPU-offline/SNC RMID handling issue. Reboot into the patched kernel after installation; live patching should only be considered sufficient if the vendor explicitly states this specific flaw is covered. If immediate patching is not possible, reduce exposure by avoiding CPU hotplug/offline operations on affected systems, disabling or limiting resctrl monitoring where operationally feasible, disabling SNC where feasible and validated for the workload, and restricting administrative interfaces or automation that can write to CPU online/offline controls. Ensure only trusted administrators can access CPU hotplug controls such as sysfs CPU online files and system management tooling.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the active kernel version with uname -a and comparing it to the relevant distribution security advisory or patched kernel changelog. Verify that systems requiring remediation have actually rebooted into the updated kernel, not merely installed it. Review whether the host exposes resctrl at /sys/fs/resctrl and whether CPU hotplug controls are available under /sys/devices/system/cpu/. On representative non-production hardware with the same SNC/resctrl configuration, validate that CPU offlining operations no longer produce kernel Oops, KASAN, UBSAN, or panic messages related to resctrl, RMID, limbo handling, cpu_to_node(), or CPU offline processing. Where kernel crash dumping is enabled, confirm no new vmcore is generated during CPU offline testing.

Typical attack path

1. Obtain local privileged access or control over a management mechanism capable of offlining CPUs.
2. Identify or rely on a vulnerable x86 Linux kernel running resctrl monitoring with SNC enabled.
3. Ensure resctrl monitoring state exists, such as active or dirty RMIDs associated with a monitoring domain.
4. Offline CPUs until a resctrl monitoring domain has no CPUs remaining in its CPU mask.
5. Trigger the resctrl limbo handler while the domain is being offlined.
6. Cause the kernel to perform an invalid CPU-to-NUMA lookup and out-of-bounds access.
7. Achieve denial of service through kernel crash, panic, or host instability.

How to detect it

Look for evidence of local or administrative CPU offlining activity followed by kernel faults involving resctrl, RMID monitoring, NUMA node lookup, or CPU hotplug. Relevant log sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, auditd records for writes to CPU online sysfs files, sudo logs, shell history where available, configuration-management logs, and crash dump directories such as /var/crash. Suspicious sequences include writes of 0 to /sys/devices/system/cpu/cpu*/online, resctrl monitoring activity under /sys/fs/resctrl, and immediate kernel Oops/panic messages mentioning resctrl, RMID, limbo, cpu_to_node, or out-of-bounds access. Since exploitation likely requires elevated local privileges, correlate any crash with privileged sessions, sudo commands, automation jobs, kernel tuning activity, and hardware maintenance tasks. Absence of these strings does not prove non-exploitation because a hard panic may truncate logs; check persistent journal storage, remote syslog, BMC/system event logs, and vmcore artifacts if available.

• /sys/fs/resctrl
• /sys/devices/system/cpu/cpu*/online
• echo 0 > /sys/devices/system/cpu/cpu
• resctrl
• RMID
• limbo
• cpu_to_node
• nr_cpu_ids
• CPU offline
• cpu offline
• smpboot: CPU
• BUG: KASAN
• UBSAN
• kernel BUG
• Oops:
• general protection fault
• panic:
• Kernel panic
• Out of bounds
• out-of-bounds
• /var/crash
• vmcore

What your security team should do

• Prioritize patching x86 Linux systems that use Intel SNC, resctrl monitoring, RMID/LLC occupancy monitoring, CPU hotplug, virtualization hosting, HPC scheduling, or automated hardware maintenance workflows.
• Inventory systems exposing /sys/fs/resctrl and systems where CPUs can be dynamically offlined through sysfs, orchestration, firmware, or management tooling.
• Restrict CPU offline/hotplug permissions to trusted administrative paths and review automation that writes to /sys/devices/system/cpu/cpu*/online.
• Monitor kernel logs for Oops, panic, KASAN, UBSAN, or general protection fault events involving resctrl, RMID, limbo handlers, CPU offlining, or cpu_to_node().
• Because this is not currently KEV-listed and has very low EPSS, schedule broadly according to normal kernel-maintenance SLAs, but accelerate remediation for availability-critical hosts where a kernel panic would cause significant disruption.
• Ensure crash dump collection is enabled on high-value Linux hosts so suspected exploitation or accidental triggering can be investigated after a panic.
• After patching, verify the system has rebooted into the fixed kernel and that old vulnerable kernels are not the default boot option.