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

Published Sep 17, 2026
·
Updated

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. ]

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    In fs/resctrl, replace the rdtgroup release/decrement-to-zero logic that currently uses atomic_dec_and_test() with atomic_dec_and_mutex_lock() so the decrement-to-zero takes rdtgroup_mutex before the count becomes zero; this prevents rdtgroup_kn_put() and bulk teardown paths (free_all_child_rdtgrp(), rmdir_all_sub()) from racing and causing use-after-free/double-free.

    Linux kernel fs/resctrl (rdtgroup) atomic_dec_and_test() usage = Replace with atomic_dec_and_mutex_lock()

Event History

Sep 17, 2026
CVE Published
via MITRE·04:11 PM
Data Sourced
via MITRE·04:11 PM
Description

Frequently Asked Questions

1

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.

2

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.

3

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203