[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220812122509.281f0536@kernel.org>
Date: Fri, 12 Aug 2022 12:25:09 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Siddh Raman Pant <code@...dh.me>
Cc: "Greg KH" <gregkh@...uxfoundation.org>,
"johannes berg" <johannes@...solutions.net>,
"david s. miller" <davem@...emloft.net>,
"eric dumazet" <edumazet@...gle.com>,
"paolo abeni" <pabeni@...hat.com>,
"netdev" <netdev@...r.kernel.org>,
"syzbot+6cb476b7c69916a0caca"
<syzbot+6cb476b7c69916a0caca@...kaller.appspotmail.com>,
"linux-wireless" <linux-wireless@...r.kernel.org>,
"linux-kernel" <linux-kernel@...r.kernel.org>,
"syzbot+f9acff9bf08a845f225d"
<syzbot+f9acff9bf08a845f225d@...kaller.appspotmail.com>,
"syzbot+9250865a55539d384347"
<syzbot+9250865a55539d384347@...kaller.appspotmail.com>,
"linux-kernel-mentees"
<linux-kernel-mentees@...ts.linuxfoundation.org>
Subject: Re: [PATCH v2] wifi: cfg80211: Fix UAF in ieee80211_scan_rx()
On Fri, 12 Aug 2022 21:57:31 +0530 Siddh Raman Pant wrote:
> On Fri, 12 Aug 2022 20:57:58 +0530 Greg KH wrote:
> > rcu just delays freeing of an object, you might just be delaying the
> > race condition. Just moving a single object to be freed with rcu feels
> > very odd if you don't have another reference somewhere.
>
> As mentioned in patch message, in net/mac80211/scan.c, we have:
> void ieee80211_scan_rx(struct ieee80211_local *local, struct sk_buff *skb)
> {
> ...
> scan_req = rcu_dereference(local->scan_req);
> sched_scan_req = rcu_dereference(local->sched_scan_req);
>
> if (scan_req)
> scan_req_flags = scan_req->flags;
> ...
> }
>
> So scan_req is probably supposed to be protected by RCU.
>
> Also, in ieee80211_local's definition at net/mac80211/ieee80211_i.h, we have:
> struct cfg80211_scan_request __rcu *scan_req;
>
> Thus, scan_req is indeed supposed to be protected by RCU, which this patch
> addresses by adding a RCU head to the type's struct, and using kfree_rcu().
>
> The above snippet is where the UAF happens (you can refer to syzkaller's log),
> because __cfg80211_scan_done() is called and frees the pointer.
Similarly to Greg, I'm not very familiar with the code base but one
sure way to move things forward would be to point out a commit which
broke things and put it in a Fixes tag. Much easier to validate a fix
by looking at where things went wrong.
Powered by blists - more mailing lists