linux-kernel - Re: [PATCH] wifi: cfg80211: fix WARN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6b59e7a5f90b85dfc9146fa2cbdfe56c0a307a3e.camel@sipsolutions.net>
Date: Wed, 13 Nov 2024 16:48:58 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Aditya Kumar Singh <quic_adisi@...cinc.com>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] wifi: cfg80211: fix WARN_ON during CAC cancelling

On Wed, 2024-11-13 at 20:13 +0530, Aditya Kumar Singh wrote:
> On 11/13/24 14:59, Johannes Berg wrote:
> > > 
> > > diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
> > > index a5eb92d93074e6ce1e08fcc2790b80cf04ff08f8..2a932a036225a3e0587cf5c18a4e80e91552313b 100644
> > > --- a/net/wireless/mlme.c
> > > +++ b/net/wireless/mlme.c
> > > @@ -1112,10 +1112,6 @@ void cfg80211_cac_event(struct net_device *netdev,
> > >   	struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
> > >   	unsigned long timeout;
> > >   
> > > -	if (WARN_ON(wdev->valid_links &&
> > > -		    !(wdev->valid_links & BIT(link_id))))
> > > -		return;
> > > -
> > >   	trace_cfg80211_cac_event(netdev, event, link_id);
> > >   
> > >   	if (WARN_ON(!wdev->links[link_id].cac_started &&
> > > 
> > 
> > This really doesn't seem right.
> > 
> > Perhaps the order in teardown should be changed?
> 
> I thought about it but couldn't really come down to a convincing approach.
> 
> The thing is when CAC in ongoing and hostapd process is killed, there is 
> no specific event apart from link delete which hostapd sends.
> 

so we do have link removal, why doesn't that work?

> Will it be 
> okay to add a new NL command to stop radar detection? Something opposite 
> of what start_radar_detection command does?
> 

No, obviously not.

johannes