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@vger.kernel.org Signed-off-by: Jiawei Ye jiawei.ye@foxmail.com Acked-by: Miquel Raynal miquel.raynal@bootlin.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.
v2 -> v3: - Add Cc stable tag and Acked-by. --- 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,
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@vger.kernel.org Signed-off-by: Jiawei Ye jiawei.ye@foxmail.com Acked-by: Miquel Raynal miquel.raynal@bootlin.com
Reviewed-by: Przemek Kitszel przemyslaw.kitszel@intel.com
Hello Jiawei Ye.
On Tue, 24 Sep 2024 06:58:05 +0000, 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.
[...]
Applied to wpan/wpan.git, thanks!
[1/1] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker https://git.kernel.org/wpan/wpan/c/bff1709b3980
regards, Stefan Schmidt
linux-stable-mirror@lists.linaro.org