linux-stable.git/fs/resctrl, branch v7.2.6

fs/resctrl: Fix UAF from worker threads when domains are removed

2026-09-14T11:39:27+00:00

[ Upstream commit 2566b5cd6a275c124e8f154fef6e815f92ec8d5c ]

The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters
and may sleep while doing so. They are scheduled via delayed_work embedded in
struct rdt_l3_mon_domain. Architecture allocates and frees these domains from
CPU hotplug callbacks under cpus_write_lock(), and the workers acquire
cpus_read_lock() to keep the domain alive across their access.

A use-after-free can occur when a worker is blocked waiting for
cpus_read_lock() while the hotplug core holds cpus_write_lock(): the
architecture frees the rdt_l3_mon_domain that contains the worker's
work_struct. When the worker unblocks, the container_of() it performs on the
embedded work pointer dereferences freed memory.

Drop cpus_read_lock() from the workers and instead drain pending and in-flight
work synchronously before the architecture can free the domain. Since
architecture offlines the domain under cpus_write_lock() after it has been
unlinked from the RCU list and a grace period has elapsed, no new work can be
scheduled. The cancel only needs to wait out existing work. Drop
rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that
a worker waiting on the mutex can complete before re-pinning the work on
a different CPU.

When offlining a CPU the architecture may iterate over resources in any order.
For example, the MBA control domain may be offlined before or after
a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers
no matter what order the architecture offlines the domains.

Fixes: 24247aeeabe9 ("x86/intel_rdt/cqm: Improve limbo list processing")
Closes: https://sashiko.dev/#/patchset/20260429184858.36423-1-tony.luck%40intel.com # [1]
Reported-by: Sashiko
Co-developed-by: Tony Luck
Signed-off-by: Tony Luck
Signed-off-by: Reinette Chatre
Signed-off-by: Borislav Petkov (AMD)
Link: https://patch.msgid.link/3f0e0752deb3421606dfc4600f0ab3a4ae098cd7.1783963505.git.reinette.chatre@intel.com
Signed-off-by: Sasha Levin

fs/resctrl: Prevent use-after-free in rdtgroup_kn_put()

2026-09-14T11:39:27+00:00

[ Upstream commit f5bcf539484d2d604c2f2330e09487ea090b21c7 ]

A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that
need the structure to remain valid across a sleep (while waiting on acquiring
rdtgroup_mutex) take a reference with rdtgroup_kn_get() and release it with
rdtgroup_kn_put().

The release path is intended to serve as the fallback freer: if the count
drops to zero and the group has already been marked RDT_DELETED,
rdtgroup_kn_put() frees the structure.

The bulk teardown paths free_all_child_rdtgrp() and rmdir_all_sub() resulting
from a resctrl directory remove or resctrl fs unmount act as the primary
freer: they hold rdtgroup_mutex and free each rdtgroup whose waitcount is
zero, otherwise they set RDT_DELETED and leave the freeing to the last waiter.

These two freers race. rdtgroup_kn_put() commits waitcount == 0 with
atomic_dec_and_test() outside rdtgroup_mutex, then reads rdtgroup::flags.
Between those two operations a concurrent caller of free_all_child_rdtgrp()
or rmdir_all_sub() (which holds the mutex) can observe waitcount == 0 via
atomic_read(), call rdtgroup_remove(), and kfree() the structure.

The subsequent read of rdtgroup::flags in rdtgroup_kn_put() is then
a use-after-free, and the structure may even be freed twice if the freed
memory happens to satisfy the RDT_DELETED flag check.

Replace the bare atomic_dec_and_test() with atomic_dec_and_mutex_lock() so
that the decrement-to-zero takes rdtgroup_mutex before the count becomes
globally visible. The inspection of rdtgroup::flags then runs under the same
mutex held by the bulk freers, making the two paths mutually exclusive.

The common case where the count does not reach zero remains lock-free. Defer
kernfs_unbreak_active_protection() until after the mutex is dropped since
kernfs active protections functionally wrap rdtgroup_mutex. Remove resource
group, which in turn drops its kernfs reference, after kernfs protection is
restored.

  [ bp: Split the commit messsages into smaller, easier-parseable paragraphs. ]

Fixes: b8511ccc75c0 ("x86/resctrl: Fix use-after-free when deleting resource groups")
Closes: https://sashiko.dev/#/patchset/20260515193944.15114-1-tony.luck%40intel.com?part=1
Reported-by: Sashiko 
Assisted-by: GitHub_Copilot:gemini-3.1-pro
Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Ben Horgan 
Reviewed-by: Tony Luck 
Link: https://patch.msgid.link/8d028bbea582dc382a4cc166b235f75bd5901aea.1783963505.git.reinette.chatre@intel.com
Signed-off-by: Sasha Levin

fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list

2026-07-07T02:05:49+00:00

A pseudo-locked group's RMID is freed when it is created. On unmount
rmdir_all_sub() unconditionally frees all RMID of all groups, resulting
in a double-free of the pseudo-locked group's RMID. The consequence of this
is that the original free results in the pseudo-locked group's RMID being
added to the rmid_free_lru linked list and the second free then attempts
to add the same RMID entry to the rmid_free_lru again.

Do not double-free a pseudo-locked group's RMID.

Fixes: e0bdfe8e36f3 ("x86/intel_rdt: Support creation/removal of pseudo-locked region")
Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Cc: 
Link: https://patch.msgid.link/551432dd7e624a862b8e58314c38aaba0afff3e9.1783377598.git.reinette.chatre@intel.com

fs/resctrl: Fix use-after-free during unmount

2026-07-07T01:50:56+00:00

During unmount or failure teardown all mon_data structures that contain
monitoring event file private data are freed after which kernfs nodes are
removed. However, the RDT_DELETED flag is never set for the statically
allocated default resource group.

A concurrent reader of an event file associated with the default resource
group may, after dropping kernfs active protection, block on rdtgroup_mutex
while unmount proceeds to free the file private data and destroy the kernfs
node without waiting for the reader.

When the mutex is released, the reader wakes up, observes that RDT_DELETED
is not set for the default group, and dereferences the already-freed
file private data.

The scenario can be depicted as follows:
  CPU0                                      CPU1
   /*
    * Default resource group's
    * monitoring data accessible via
    * kernfs file with kernfs_node::priv
    * pointing to a struct mon_data.
    * User opens the file for reading.
    */
   rdtgroup_mondata_show()                 /* arch encounters fatal error */
    rdtgroup_kn_lock_live()                 resctrl_exit()
     atomic_inc(&rdtgroup_default.waitcount) cpus_read_lock()
     kernfs_break_active_protection(kn)      mutex_lock(&rdtgroup_mutex)
     cpus_read_lock()                        resctrl_fs_teardown()
     mutex_lock(&rdtgroup_mutex)              rmdir_all_sub()
                                              mon_put_kn_priv()
                                               /* Delete all mon_data structures */
                                              rdtgroup_destroy_root()
                                               kernfs_destroy_root()
                                               rdtgroup_default.kn = NULL
                                             mutex_unlock(&rdtgroup_mutex)
     /*
      * rdtgroup_default.flags is empty so
      * rdtgroup_kn_lock_live() returns
      * &rdtgroup_default
      */
     md = of->kn->priv;

     /* md points to freed mon_data */

Set RDT_DELETED for the default group unconditionally since the flag does
not lead to the freeing of this statically allocated group.

Do not allow a new resctrl mount if there are any waiters on default group
of previous mount. A new mount will re-initialize the default group that
would appear to waiters from previous mount as though the default group is
accessible causing them to access the mon_data structures from the previous
mount that have been removed.

Fixes: 2a6566038544 ("x86/resctrl: Expand the width of domid by replacing mon_data_bits")
Closes: https://sashiko.dev/#/patchset/20260508182143.14592-1-tony.luck%40intel.com?part=2 [1]
Reported-by: Sashiko 
Signed-off-by: Tony Luck 
Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Chen Yu 
Cc: 
Link: https://patch.msgid.link/49a2ca3ca688f27e1a646cf90e1dc69287021127.1783377598.git.reinette.chatre@intel.com

fs/resctrl: Free mon_data structures on rdt_get_tree() failure

2026-07-07T00:42:38+00:00

If mkdir_mondata_all() or a subsequent call in rdt_get_tree() fails, the
mon_data structures allocated by mon_get_kn_priv() are leaked.

Add mon_put_kn_priv() to the out_mongrp error path to free the mon_data
structures.

Fixes: 2a6566038544 ("x86/resctrl: Expand the width of domid by replacing mon_data_bits")
Closes: https://lore.kernel.org/lkml/5d38c1fb-8f91-472b-8897-24b2f50c772b@intel.com/
Reported-by: Reinette Chatre 
Signed-off-by: Tony Luck 
Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Chen Yu 
Reviewed-by: Ben Horgan 
Cc: 
Link: https://patch.msgid.link/433623b7e3316ffd52323255d1aa4f156ad97cb1.1783377598.git.reinette.chatre@intel.com

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

2026-07-01T20:15:02+00:00

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.

Fixes: e13db55b5a0d ("x86/resctrl: Introduce snc_nodes_per_l3_cache")
Closes: https://sashiko.dev/#/patchset/cover.1780456704.git.reinette.chatre%40intel.com?part=9
Reported-by: Sashiko 
Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov (AMD) 
Cc: 
Link: https://patch.msgid.link/16137433df42f85013b2f7a53626795cbd6637b9.1781029125.git.reinette.chatre@intel.com

fs/resctrl: Continue counter allocation after failure

2026-05-08T10:07:43+00:00

In mbm_event mode, with mbm_assign_on_mkdir set to 1, when a user creates a
new CTRL_MON or MON group resctrl attempts to allocate counters for each of
the supported MBM events on each resctrl domain. As counters are limited,
such allocation may fail and when it does counter allocations for the
remaining domains are skipped even if the domains have available counters.

Because of that, the user needs to view the resource group'smbm_L3_assignments
file to get an accurate view of counter assignment in a new resource group and
then manually create counters in the skipped domains with available counters.

Writes to mbm_L3_assignments using the wildcard format, :*=e, also skip
counter allocation in other domains after a counter allocation failure.

When handling a request to create counters in all domains it is unnecessary
for a counter allocation in one domain to prevent counter allocation in
other domains. Always attempt to allocate all the counters requested.

  [ bp: Massage commit message. ]

Signed-off-by: Ben Horgan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Babu Moger 
Reviewed-by: Reinette Chatre 
Tested-by: Babu Moger 
Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com

fs/resctrl: Add monitor property 'mbm_cntr_assign_fixed'

2026-05-07T14:29:14+00:00

Commit

  3b497c3f4f04 ("fs/resctrl: Introduce the interface to display monitoring modes")

introduced CONFIG_RESCTRL_ASSIGN_FIXED but left adding the Kconfig
entry until it was necessary. The counter assignment mode is fixed in
MPAM, even when there are assignable counters, and so addressing this
is needed to support MPAM.

To avoid the burden of another Kconfig entry, replace
CONFIG_RESCTRL_ASSIGN_FIXED with a new property in 'struct resctrl_mon',
'mbm_cntr_assign_fixed' to be set by the architecture.

Do not request the architecture to change the counter assignment mode if it
does not support doing so. Provide insight to user space about why such a
request fails.

Signed-off-by: Ben Horgan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Babu Moger 
Reviewed-by: Reinette Chatre 
Tested-by: Babu Moger 
Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com

fs/resctrl: Disallow the software controller when MBM counters are assignable

2026-05-06T17:06:57+00:00

The software controller requires that there is one MBM counter per monitor
group that is assigned to the event backing the software controller, as per
mba_MBps_event. When mbm_event mode is in use, it is not guaranteed that any
particular event will have an assigned counter.

Currently, only AMD systems support counter assignment, but the MBA delay
is non-linear and so the software controller is never supported anyway. On
MPAM systems, the MBA delay is linear and so the software controller could
be supported. The MPAM driver, unless a need arises, will not support the
'default' mbm_assign_mode and will always use the 'mbm_event' mode for
memory bandwidth monitoring.

Rather than develop a way to guarantee the counter assignment requirements
needed by the software controller, take the pragmatic approach. Don't allow
the software controller to be used at the same time as 'mbm_event' mode. As
MPAM is the only relevant architecture and it will use 'mbm_event' mode
whenever there are assignable MBM counters, for simplicity's sake, don't
allow the software controller when the MBM counters are assignable.

Implement this by failing the mount if the user requests the software
controller, the mba_MBps option, and the MBM counters are assignable.

Signed-off-by: Ben Horgan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Reinette Chatre 
Reviewed-by: Babu Moger 
Tested-by: Babu Moger 
Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com

x86,fs/resctrl: Create 'event_filter' files read only if they're not configurable

2026-05-06T17:06:57+00:00

When the counter assignment mode is mbm_event resctrl assumes the MBM
events are configurable and exposes the 'event_filter' files. These files
live at info/L3_MON/event_configs//event_filter and are used to
display and set the event configuration.

The MPAM architecture has support for configuring the memory bandwidth
utilization (MBWU) counters to only count reads or only count
writes. However, in MPAM, this event filtering support is optional in the
hardware (and not yet implemented in the MPAM driver) but MBM counter
assignment is always possible for MPAM MBWU counters.

In order to support mbm_event mode with MPAM, create the 'event_filter'
files read only if the event configuration can't be changed. A user can
still chmod the file and so also return early with an error from
event_filter_write().

Introduce a new monitor property, mbm_cntr_configurable, to indicate
whether or not assignable MBM counters are configurable. On x86, set this
to true whenever mbm_cntr_assignable is true to keep existing behaviour.

Signed-off-by: Ben Horgan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Reinette Chatre 
Reviewed-by: Babu Moger 
Tested-by: Babu Moger 
Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com