Linux wireless drivers development
 help / color / mirror / Atom feed
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