From: Al Viro <viro@zeniv.linux.org.uk>
To: Moon Hee Lee <moonhee.lee.ca@gmail.com>
Cc: syzbot+d6ccd49ae046542a0641@syzkaller.appspotmail.com,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
hdanton@sina.com
Subject: Re: [syzbot] [fs?] [wireless?] general protection fault in simple_recursive_removal (5)
Date: Thu, 31 Jul 2025 18:28:52 +0100 [thread overview]
Message-ID: <20250731172852.GQ222315@ZenIV> (raw)
In-Reply-To: <20250731171729.46432-2-moonhee.lee.ca@gmail.com>
On Thu, Jul 31, 2025 at 10:17:29AM -0700, Moon Hee Lee wrote:
> #syz test git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
>
>
> Thanks for the review and valuable feedback.
>
> Upon investigation, I found the crash occurs when the netdev's debugfs
> directory is removed while a station still holds a pointer
> (sta->debugfs_dir) to a dentry within it. A subsequent call to
> ieee80211_sta_debugfs_remove() may then dereference a freed dentry,
> triggering a use-after-free.
>
> To address this, I’m preparing a patch that clears sta->debugfs_dir for
> all stations associated with the interface before calling
> debugfs_remove_recursive(). This ensures any later station removal
> becomes a no-op and avoids referencing a stale pointer.
>
> This reply is intended for syz testing and to provide context for
> review. A formal patch will follow.
> + /*
> + * Before we delete the netdev’s debugfs tree, clear sta->debugfs_dir
> + * for every station on this interface. This ensures any later call to
> + * ieee80211_sta_debugfs_remove() sees NULL and avoids touching a dentry
> + * that we are about to free.
> + */
> + rcu_read_lock();
> + list_for_each_entry_rcu(sta, &sdata->local->sta_list, list) {
> + if (sta->sdata == sdata)
> + sta->debugfs_dir = NULL;
> + }
> + rcu_read_unlock();
Umm... Is there any exclusion between that an ieee80211_sta_debugfs_remove()?
This looks fishy...
next prev parent reply other threads:[~2025-07-31 17:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-31 17:17 [syzbot] [fs?] [wireless?] general protection fault in simple_recursive_removal (5) Moon Hee Lee
2025-07-31 17:28 ` Al Viro [this message]
2025-07-31 17:40 ` syzbot
-- strict thread matches above, loose matches on Subject: below --
2025-07-24 6:40 Moon Hee Lee
2025-07-24 7:03 ` syzbot
2025-07-24 15:58 ` Al Viro
2025-07-24 17:29 ` Moon Hee Lee
2025-07-24 23:34 ` Hillf Danton
2025-07-25 0:20 ` Al Viro
2025-07-24 6:17 Moon Hee Lee
2025-07-24 6:17 ` syzbot
2025-07-24 6:08 Moon Hee Lee
2025-07-24 6:08 ` syzbot
2025-07-23 17:19 syzbot
2025-07-24 2:22 ` Hillf Danton
2025-07-24 2:40 ` syzbot
2025-07-24 3:34 ` Hillf Danton
2025-07-24 3:56 ` syzbot
2025-07-24 10:22 ` Hillf Danton
2025-07-24 10:44 ` syzbot
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=20250731172852.GQ222315@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=moonhee.lee.ca@gmail.com \
--cc=syzbot+d6ccd49ae046542a0641@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/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.