From: Ben Greear <greearb@candelatech.com>
To: linux-wireless <linux-wireless@vger.kernel.org>
Subject: RFC: Potential fix for inode use-after-free
Date: Mon, 2 Mar 2026 15:29:52 -0800 [thread overview]
Message-ID: <51a8ef48-d1a7-098e-57c3-868d3183a650@candelatech.com> (raw)
Hello,
I was hitting a tricky case where debugfs inodes were being used
after they were freed (more of a double free attempt, really).
I tried multiple things, but this is the last thing that I tried
and it seems to have fixed things. I believe the other stuff I
tried (adding a spin lock, other sanity checking) didn't actually
make a difference, but I've left logs in place if I do run into
more troubles...
For reasons not entirely clear, I was seeing a logging message indicating
that a station was being deleted while links were still active.
I believe that the problem then becomes when the netdev calls the
debugfs_remove_recursive, the inodes for the link's debugfs are
deleted, but links still have a pointer to it, and would later try
to clear their own debugfs.
So, explicitly NULL out any link inodes when removing the netdev debugfs.
I'm not that confident that I didn't somehow break this with other
local changes..but if someone else hits a similar problem, maybe
it is worth cleaning this up and making a real patch.
In net/mac80211/debugfs_netdev.c
void ieee80211_debugfs_remove_netdev(struct ieee80211_sub_if_data *sdata)
{
- if (!sdata->vif.debugfs_dir)
+ struct dentry* dir = sdata->vif.debugfs_dir;
+ struct ieee80211_link_data *link;
+ int i;
+
+ if (!dir)
return;
- debugfs_remove_recursive(sdata->vif.debugfs_dir);
sdata->vif.debugfs_dir = NULL;
+
+ /* In case where there were errors on station creation and maybe
+ * teardown, we may get here with some links still active. We are
+ * about to recursively delete debugfs, so remove any pointers the
+ * links may have.
+ */
+ rcu_read_lock();
+
+ for (i = 0; i<IEEE80211_MLD_MAX_NUM_LINKS; i++) {
+ link = rcu_access_pointer(sdata->link[i]);
+ if (!link)
+ continue;
+
+ if (dir == link->lnk_debugfs_dir) {
+ /* Deflink sharing our pointer, probably..clear but do not warn. */
+ link->lnk_debugfs_dir = NULL;
+ } else if (link->lnk_debugfs_dir) {
+ sdata_info(sdata, "Nulling link %i debugfs dir in remove-netdev",
+ i);
+ link->lnk_debugfs_dir = NULL;
+ }
+ }
+ rcu_read_unlock();
+
+ debugfs_remove_recursive(dir);
sdata->debugfs.subdir_stations = NULL;
}
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
reply other threads:[~2026-03-02 23:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=51a8ef48-d1a7-098e-57c3-868d3183a650@candelatech.com \
--to=greearb@candelatech.com \
--cc=linux-wireless@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox