netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker
@ 2024-09-20  4:03 Jiawei Ye
  2024-09-20 11:21 ` Miquel Raynal
  0 siblings, 1 reply; 4+ messages in thread
From: Jiawei Ye @ 2024-09-20  4:03 UTC (permalink / raw)
  To: przemyslaw.kitszel
  Cc: alex.aring, stefan, miquel.raynal, davem, edumazet, kuba, pabeni,
	david.girault, linux-wpan, netdev, linux-kernel

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@foxmail.com>

---
Changelog:

v1->v2: -Repositioned the enum nl802154_scan_types scan_req_type
declaration between struct cfg802154_scan_request *scan_req and struct
ieee802154_sub_if_data *sdata to comply with the reverse Christmas tree
rule.
---
 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..a6dab3cc3ad8 100644
--- a/net/mac802154/scan.c
+++ b/net/mac802154/scan.c
@@ -176,6 +176,7 @@ void mac802154_scan_worker(struct work_struct *work)
 	struct ieee802154_local *local =
 		container_of(work, struct ieee802154_local, scan_work.work);
 	struct cfg802154_scan_request *scan_req;
+	enum nl802154_scan_types scan_req_type;
 	struct ieee802154_sub_if_data *sdata;
 	unsigned int scan_duration = 0;
 	struct wpan_phy *wpan_phy;
@@ -209,6 +210,7 @@ void mac802154_scan_worker(struct work_struct *work)
 	}
 
 	wpan_phy = scan_req->wpan_phy;
+	scan_req_type = scan_req->type;
 	scan_req_duration = scan_req->duration;
 
 	/* Look for the next valid chan */
@@ -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,
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker
  2024-09-20  4:03 [PATCH v2] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker Jiawei Ye
@ 2024-09-20 11:21 ` Miquel Raynal
  2024-09-21  5:22   ` Jiawei Ye
  0 siblings, 1 reply; 4+ messages in thread
From: Miquel Raynal @ 2024-09-20 11:21 UTC (permalink / raw)
  To: Jiawei Ye
  Cc: przemyslaw.kitszel, alex.aring, stefan, davem, edumazet, kuba,
	pabeni, david.girault, linux-wpan, netdev, linux-kernel

Hi Jiawei,

jiawei.ye@foxmail.com wrote on Fri, 20 Sep 2024 04:03:32 +0000:

> 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@foxmail.com>

I think net maintainers now expect the Cc: stable tag to be put here
when there is a reason to backport, which I believe is the case here.
So please add this line here.

> 

Please delete this blank line as well.

And with that you can add my:

Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>

> ---

Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker
  2024-09-20 11:21 ` Miquel Raynal
@ 2024-09-21  5:22   ` Jiawei Ye
  2024-09-23 12:40     ` Stefan Schmidt
  0 siblings, 1 reply; 4+ messages in thread
From: Jiawei Ye @ 2024-09-21  5:22 UTC (permalink / raw)
  To: miquel.raynal
  Cc: alex.aring, davem, david.girault, edumazet, jiawei.ye, kuba,
	linux-kernel, linux-wpan, netdev, pabeni, przemyslaw.kitszel,
	stefan

Hi Miquèl,

I'm sorry for the accidental email sent while testing my email setup. Please disregard the previous message.

On 9/20/24 19:21, Miquel Raynal wrote:
> Hi Jiawei,
> 
> jiawei.ye@foxmail.com wrote on Fri, 20 Sep 2024 04:03:32 +0000:
> 
> > 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@foxmail.com>
> 
> I think net maintainers now expect the Cc: stable tag to be put here
> when there is a reason to backport, which I believe is the case here.
> So please add this line here.
> 

Does this mean I should use Cc: stable@vger.kernel.org? I am not familiar with this procedure.

> > 
> 
> Please delete this blank line as well.
> 
> And with that you can add my:
> 
> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
> 
> > ---
> 
> Thanks,
> Miquèl

Do I need to resend patch v2 with the "Resend" label?

Thank you for your assistance.

Best regards,
Jiawei Ye


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH v2] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker
  2024-09-21  5:22   ` Jiawei Ye
@ 2024-09-23 12:40     ` Stefan Schmidt
  0 siblings, 0 replies; 4+ messages in thread
From: Stefan Schmidt @ 2024-09-23 12:40 UTC (permalink / raw)
  To: Jiawei Ye, miquel.raynal
  Cc: alex.aring, davem, david.girault, edumazet, kuba, linux-kernel,
	linux-wpan, netdev, pabeni, przemyslaw.kitszel

Hello.

On 9/21/24 07:22, Jiawei Ye wrote:
> Hi Miquèl,
> 
> I'm sorry for the accidental email sent while testing my email setup. Please disregard the previous message.
> 
> On 9/20/24 19:21, Miquel Raynal wrote:
>> Hi Jiawei,
>>
>> jiawei.ye@foxmail.com wrote on Fri, 20 Sep 2024 04:03:32 +0000:
>>
>>> 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@foxmail.com>
>>
>> I think net maintainers now expect the Cc: stable tag to be put here
>> when there is a reason to backport, which I believe is the case here.
>> So please add this line here.
>>
> 
> Does this mean I should use Cc: stable@vger.kernel.org? I am not familiar with this procedure.

Yes.

>>>
>>
>> Please delete this blank line as well.
>>
>> And with that you can add my:
>>
>> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
>>
>>> ---
>>
>> Thanks,
>> Miquèl
> 
> Do I need to resend patch v2 with the "Resend" label?

Please make it a v3 right away, the resend with changes is to confusing 
for maintainers to keep up what to apply.

In your case remove the blank line, add the stable cc and I am happy to 
apply this.

regards
Stefan Schmidt

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-09-23 12:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-20  4:03 [PATCH v2] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker Jiawei Ye
2024-09-20 11:21 ` Miquel Raynal
2024-09-21  5:22   ` Jiawei Ye
2024-09-23 12:40     ` Stefan Schmidt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).