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.
