CVE-2026-64477

x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled

N/A
Published: July 25, 2026 at 08:51 AM UTC
Updated: August 17, 2026 at 05:17 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled The architecture updates the cpu_mask in a domain's header to track which online CPUs are associated with the domain. When this mask becomes empty the architecture initiates offline of the domain that includes calling on resctrl fs to offline the domain. If it is a monitoring domain in which LLC occupancy is tracked resctrl fs forces the limbo handler to clear all busy RMID state associated with the domain. The limbo handler always reads the current event value associated with a busy RMID irrespective of it being checked as part of regular "is it still busy" check or whether it will be forced released anyway. When reading an RMID on a system with SNC enabled the "logical RMID" is converted to the "physical RMID" and this conversion requires the NUMA node ID of the resctrl monitoring domain that is in turn determined by querying the NUMA node ID of any CPU belonging to the monitoring domain. When the monitoring domain is going offline its cpu_mask is empty causing the NUMA node ID query via cpu_to_node() to be done with "nr_cpu_ids" as argument resulting in an out-of-bounds access. Refactor the limbo handler to skip reading the RMID when the RMID will just be forced to no longer be dirty in the domain anyway. Add a safety check to the architecture's RMID reader to protect against this scenario.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

6.11 ≤ v < 6.12.966.11 ≤ v < 6.18.396.11 ≤ v < 7.1.46.11 ≤ v < 7.26.11e13db55b5a0d447dea63cde772c1078405bbbf96
Vendor states this is fixed in 58c5ec23b1a238eb75cb0aba6f69d8f9e68ef0b2 (fixed)
Vendor states this is fixed in be1567992417dc92133e74126de7a6066c825ac9 (fixed)
Vendor states this is fixed in ebc300b7ee0c669fa76a7a8858298ff32e296103 (fixed)
Vendor states this is fixed in fc16126cc11d9f507130bf84ab137ee0938c900e (fixed)
Vendor states this is fixed in 6.11 (unaffected)
Vendor states this is fixed in 6.12.96 (unaffected)
Vendor states this is fixed in 6.18.39 (unaffected)
Vendor states this is fixed in 7.1.4 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card