CVE-2026-64477

Unknown

Last modified

CVE-2026-64477 is a vulnerability of currently unknown severity. 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.

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 Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= e13db55b5a0d447dea63cde772c1078405bbbf96, < ebc300b7ee0c669fa76a7a8858298ff32e296103; >= e13db55b5a0d447dea63cde772c1078405bbbf96, < be1567992417dc92133e74126de7a6066c825ac9; >= e13db55b5a0d447dea63cde772c1078405bbbf96, < 58c5ec23b1a238eb75cb0aba6f69d8f9e68ef0b2; >= e13db55b5a0d447dea63cde772c1078405bbbf96, < fc16126cc11d9f507130bf84ab137ee0938c900e
LinuxLinux6.11

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-64477?
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.
How severe is CVE-2026-64477?
Severity scoring for CVE-2026-64477 is pending analysis.
How do I fix CVE-2026-64477?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-64477?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST