From: Chen Yu <yu.c.chen@intel.com>
To: reinette.chatre@intel.com
Cc: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com,
babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com,
peternewman@google.com, linux-kernel@vger.kernel.org,
patches@lists.linux.dev, Chen Yu <yu.c.chen@intel.com>
Subject: Re: [PATCH v3 3/9] fs/resctrl: Fix use-after-free during unmount
Date: Thu, 28 May 2026 21:48:10 +0800 [thread overview]
Message-ID: <20260528134810.337000-1-yu.c.chen@intel.com> (raw)
In-Reply-To: <0a48bc36304da0fce4525672cca5f41c3d8ae678.1779476724.git.reinette.chatre@intel.com>
On Fri, 22 May 2026 12:15:07 -0700, Reinette Chatre wrote:
> 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.
I wonder if a code call sequence could be added in the commit log,
which would be helpful to quickly understand the race condition:
CPU 0 (read mon_data file) CPU 1 (umount)
-------------------------- --------------
rdtgroup_kn_lock_live()
rdtgrp = &rdtgroup_default
waitcount++
break_active_protection()
mutex_lock()
mon_put_kn_priv()
kfree(mon_data)
mutex_unlock()
mutex_lock()
rdtgrp->flags & RDT_DELETED?
// no -- never set for default
return rdtgrp
md = of->kn->priv // UAF: freed
I did not find issues in current implementation,
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
next prev parent reply other threads:[~2026-05-28 13:57 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 19:15 [PATCH v3 0/9] x86,fs/resctrl: Fix long-standing issues Reinette Chatre
2026-05-22 19:15 ` [PATCH v3 1/9] fs/resctrl: Move functions to avoid forward references in subsequent fixes Reinette Chatre
2026-05-28 10:06 ` Ben Horgan
2026-05-22 19:15 ` [PATCH v3 2/9] fs/resctrl: Free mon_data structures on rdt_get_tree() failure Reinette Chatre
2026-05-27 15:18 ` Ben Horgan
2026-05-22 19:15 ` [PATCH v3 3/9] fs/resctrl: Fix use-after-free during unmount Reinette Chatre
2026-05-28 9:45 ` Ben Horgan
2026-05-28 16:09 ` Reinette Chatre
2026-05-28 13:48 ` Chen Yu [this message]
2026-05-28 16:09 ` Reinette Chatre
2026-05-22 19:15 ` [PATCH v3 4/9] fs/resctrl: Fix deadlock for errors during mount Reinette Chatre
2026-05-28 10:11 ` Ben Horgan
2026-05-29 14:06 ` Chen, Yu C
2026-05-29 15:53 ` Reinette Chatre
2026-05-31 8:41 ` Chen, Yu C
2026-05-22 19:15 ` [PATCH v3 5/9] fs/resctrl: Prevent use-after-free in rdtgroup_kn_put() Reinette Chatre
2026-05-28 10:51 ` Ben Horgan
2026-05-22 19:15 ` [PATCH v3 6/9] fs/resctrl: Fix pseudo-locking lifetime handling Reinette Chatre
2026-05-28 10:56 ` Ben Horgan
2026-05-28 16:10 ` Reinette Chatre
2026-05-22 19:15 ` [PATCH v3 7/9] fs/resctrl: Prevent deadlock and use-after-free in info file handlers Reinette Chatre
2026-05-22 19:15 ` [PATCH v3 8/9] x86/resctrl: Ensure domain fully initialized before placed on RCU list Reinette Chatre
2026-05-28 16:11 ` Reinette Chatre
2026-05-28 19:04 ` Babu Moger
2026-05-28 20:56 ` Reinette Chatre
2026-05-28 23:10 ` Moger, Babu
2026-05-31 8:37 ` Chen, Yu C
2026-06-01 15:40 ` Reinette Chatre
2026-05-22 19:15 ` [PATCH v3 9/9] fs/resctrl: Fix UAF from worker threads when domains are removed Reinette Chatre
2026-05-26 15:32 ` Luck, Tony
2026-05-26 17:53 ` Reinette Chatre
2026-05-26 18:27 ` Luck, Tony
2026-05-26 21:05 ` Reinette Chatre
2026-05-26 21:26 ` Luck, Tony
2026-05-27 1:49 ` Reinette Chatre
2026-05-28 16:12 ` Reinette Chatre
2026-05-28 20:08 ` [PATCH v3 0/9] x86,fs/resctrl: Fix long-standing issues Luck, Tony
2026-05-29 18:37 ` Reinette Chatre
2026-05-29 19:06 ` Luck, Tony
2026-05-29 20:19 ` Reinette Chatre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260528134810.337000-1-yu.c.chen@intel.com \
--to=yu.c.chen@intel.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=ben.horgan@arm.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=fenghuay@nvidia.com \
--cc=fustini@kernel.org \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=peternewman@google.com \
--cc=reinette.chatre@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.