[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cf07ed35-836b-4d1b-a934-8af2b4cc3bfe@intel.com>
Date: Tue, 24 Sep 2024 11:12:13 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Jiawei Ye <jiawei.ye@...mail.com>
CC: <alex.aring@...il.com>, <davem@...emloft.net>,
<stefan@...enfreihafen.org>, <david.girault@...vo.com>,
<edumazet@...gle.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>, <stable@...r.kernel.org>
Subject: Re: [PATCH v3] mac802154: Fix potential RCU dereference issue in
mac802154_scan_worker
On 9/24/24 08:58, Jiawei Ye 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")
> Cc: stable@...r.kernel.org
> Signed-off-by: Jiawei Ye <jiawei.ye@...mail.com>
> Acked-by: Miquel Raynal <miquel.raynal@...tlin.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Powered by blists - more mailing lists