CVE-2026-93100: fs/resctrl: Prevent use-after-free in rdtgroup_kn_put()
In the Linux kernel, the following vulnerability has been resolved:
fs/resctrl: Prevent use-after-free in rdtgroupknput()
A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that need the structure to remain valid across a sleep (while waiting on acquiring rdtgroupmutex) take a reference with rdtgroupknget() and release it with rdtgroupknput().
The release path is intended to serve as the fallback freer: if the count drops to zero and the group has already been marked RDTDELETED, rdtgroupknput() frees the structure.
The bulk teardown paths freeallchildrdtgrp() and rmdirallsub() resulting from a resctrl directory remove or resctrl fs unmount act as the primary freer: they hold rdtgroupmutex and free each rdtgroup whose waitcount is zero, otherwise they set RDTDELETED and leave the freeing to the last waiter.
These two freers race. rdtgroupknput() commits waitcount == 0 with atomicdecandtest() outside rdtgroupmutex, then reads rdtgroup::flags. Between those two operations a concurrent caller of freeallchildrdtgrp() or rmdirallsub() (which holds the mutex) can observe waitcount == 0 via atomicread(), call rdtgroupremove(), and kfree() the structure.
The subsequent read of rdtgroup::flags in rdtgroupknput() is then a use-after-free, and the structure may even be freed twice if the freed memory happens to satisfy the RDTDELETED flag check.
Replace the bare atomicdecandtest() with atomicdecandmutexlock() so that the decrement-to-zero takes rdtgroupmutex 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 kernfsunbreakactiveprotection() until after the mutex is dropped since kernfs active protections functionally wrap rdtgroupmutex. 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. ]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.114 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.52 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.12-1Fixed in 7.2.14-1 - Compensating control
In fs/resctrl, replace the bare atomic_dec_and_test() in rdtgroup_kn_put() with atomic_dec_and_mutex_lock() so the decrement-to-zero acquires rdtgroup_mutex before the count becomes globally visible.
- Compensating control
Defer kernfs_unbreak_active_protection() until after rdtgroup_mutex is dropped, and remove the resource group only after kernfs protection is restored.
Event History
Frequently Asked Questions
What conditions are needed to trigger this race?
The race requires concurrent reference release in rdtgroup_kn_put() and bulk resctrl teardown through free_all_child_rdtgrp() or rmdir_all_sub(). The affected teardown operations occur when removing a resctrl directory or unmounting the resctrl filesystem.
Which resctrl objects are involved?
The issue concerns struct rdtgroup instances that have a waitcount reference held while a caller sleeps waiting to acquire rdtgroup_mutex. A group can be freed by teardown after waitcount reaches zero while rdtgroup_kn_put() still accesses its flags.
How can systems be remediated?
Apply a kernel update containing the upstream fixes referenced by the provided stable commits. The supplied data does not identify affected or fixed kernel version ranges.