linux-kernel - Re: [PATCH] Fix the RCU usage in mac802154_scan

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <tencent_8C653C3534893CF0BC88A43A2831CDA2260A@qq.com>
Date: Thu, 19 Sep 2024 12:26:17 +0000
From: Jiawei Ye <jiawei.ye@...mail.com>
To: przemyslaw.kitszel@...el.com
Cc: alex.aring@...il.com,
	davem@...emloft.net,
	david.girault@...vo.com,
	edumazet@...gle.com,
	jiawei.ye@...mail.com,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	linux-wpan@...r.kernel.org,
	miquel.raynal@...tlin.com,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	stefan@...enfreihafen.org
Subject: Re: [PATCH] Fix the RCU usage in mac802154_scan_worker

On 9/19/24 17:01, Przemek Kitszel wrote:
> > In the `mac802154_scan_worker` function, the `scan_req->type` field was
> > accessed after the RCU read-side critical section was unlocked. According
> > to RCU usage rules, this is illegal and can lead to unpredictable
> > behavior, such as accessing memory that has been updated or causing
> > use-after-free issues.
> > 
> > This possible bug was identified using a static analysis tool developed
> > by myself, specifically designed to detect RCU-related issues.
> > 
> > To address this, the `scan_req->type` value is now stored in a local
> > variable `scan_req_type` while still within the RCU read-side critical
> > section. The `scan_req_type` is then used after the RCU lock is released,
> > ensuring that the type value is safely accessed without violating RCU
> > rules.
> > 
> > Fixes: e2c3e6f53a7a ("mac802154: Handle active scanning")
> > Signed-off-by: Jiawei Ye <jiawei.ye@...mail.com>
> > ---
> >   net/mac802154/scan.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/net/mac802154/scan.c b/net/mac802154/scan.c
> > index 1c0eeaa76560..29cd84c9f69c 100644
> > --- a/net/mac802154/scan.c
> > +++ b/net/mac802154/scan.c
> > @@ -180,6 +180,7 @@ void mac802154_scan_worker(struct work_struct *work)
> >   	unsigned int scan_duration = 0;
> >   	struct wpan_phy *wpan_phy;
> >   	u8 scan_req_duration;
> > +	enum nl802154_scan_types scan_req_type;
> 
> this line violates the reverse X-mass tree rule of code formatting

Thank you for pointing out the concern regarding the violation of the
reverse Christmas tree rule. I will adjust the placement of 
`enum nl802154_scan_types scan_req_type` to be between 
`struct cfg802154_scan_request *scan_req` and 
`struct ieee802154_sub_if_data *sdata`. If this change is suitable,
should I resend the patch as a v2 patch?

> 
> >   	u8 page, channel;
> >   	int ret;
> >   
> > @@ -210,6 +211,7 @@ void mac802154_scan_worker(struct work_struct *work)
> >   
> >   	wpan_phy = scan_req->wpan_phy;
> 
> this line (not yours) just saves the first level of pointer, but then
> accesses wpan_phy->... outside of the rcu_read_lock() section, for me
> it's very similar case to what you are fixing here
> 

According to the RCU usage rules, the value returned by `rcu_dereference()`
should be safely dereferenced only within the RCU read-side critical
section. It is important to note that `wpan_phy` is not obtained through
`rcu_dereference()`, so in this context, it may not be sufficient to infer
whether it is protected by RCU.

> >   	scan_req_duration = scan_req->duration;
> > +	scan_req_type = scan_req->type;
> >   
> >   	/* Look for the next valid chan */
> >   	page = local->scan_page;
> > @@ -246,7 +248,7 @@ void mac802154_scan_worker(struct work_struct *work)
> >   		goto end_scan;
> >   	}
> >   
> > -	if (scan_req->type == NL802154_SCAN_ACTIVE) {
> > +	if (scan_req_type == NL802154_SCAN_ACTIVE) {
> >   		ret = mac802154_transmit_beacon_req(local, sdata);
> >   		if (ret)
> >   			dev_err(&sdata->dev->dev,