kernel/linux.git/net/mac802154/scan.c, branch v7.0.10

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

mac802154: Fix potential RCU dereference issue in mac802154_scan_worker

2024-09-24T09:53:50+00:00

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 Acked-by: Miquel Raynal Reviewed-by: Przemek Kitszel Link: https://lore.kernel.org/tencent_3B2F4F2B4DA30FAE2F51A9634A16B3AD4908@qq.com Signed-off-by: Stefan Schmidt

mac802154: Only allow PAN controllers to process association requests

2023-12-15T10:14:53+00:00

It is not very clear in the specification whether simple coordinators are allowed or not to answer to association requests themselves. As there is no synchronization mechanism, it is probably best to rely on the relay feature of these coordinators and avoid processing them in this case. Signed-off-by: Miquel Raynal Acked-by: Stefan Schmidt Acked-by: Alexander Aring Link: https://lore.kernel.org/linux-wpan/20231128111655.507479-4-miquel.raynal@bootlin.com

mac80254: Provide real PAN coordinator info in beacons

2023-12-15T10:14:49+00:00

Sending a beacon is a way to advertise a PAN, but also ourselves as coordinator in the PAN. There is only one PAN coordinator in a PAN, this is the device without parent (not associated itself to an "upper" coordinator). Instead of blindly saying that we are the PAN coordinator, let's actually use our internal information to fill this field. Signed-off-by: Miquel Raynal Acked-by: Stefan Schmidt Acked-by: Alexander Aring Link: https://lore.kernel.org/linux-wpan/20231128111655.507479-2-miquel.raynal@bootlin.com

mac802154: Handle disassociation notifications from peers

2023-11-20T10:43:33+00:00

Peers may decided to disassociate from us, their coordinator, in this case they will send a disassociation notification which we must acknowledge. If we don't, the peer device considers itself disassociated anyway. We also need to drop the reference to this child from our internal structures. Signed-off-by: Miquel Raynal Acked-by: Stefan Schmidt Acked-by: Alexander Aring Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-11-miquel.raynal@bootlin.com

mac802154: Follow the number of associated devices

2023-11-20T10:43:19+00:00

Track the count of associated devices. Limit the number of associations using the value provided by the user if any. If we reach the maximum number of associations, we tell the device we are at capacity. If the user do not want to accept any more associations, it may specify the value 0 to the maximum number of associations, which will lead to an access denied error status returned to the peers trying to associate. Signed-off-by: Miquel Raynal Acked-by: Stefan Schmidt Acked-by: Alexander Aring Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-10-miquel.raynal@bootlin.com

mac802154: Handle association requests from peers

2023-11-20T10:43:03+00:00

Coordinators may have to handle association requests from peers which want to join the PAN. The logic involves: - Acknowledging the request (done by hardware) - If requested, a random short address that is free on this PAN should be chosen for the device. - Sending an association response with the short address allocated for the peer and expecting it to be ack'ed. If anything fails during this procedure, the peer is considered not associated. Signed-off-by: Miquel Raynal Acked-by: Stefan Schmidt Acked-by: Alexander Aring Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-8-miquel.raynal@bootlin.com

mac802154: Handle disassociations

2023-11-20T10:42:55+00:00

Devices may decide to disassociate from their coordinator for different reasons (device turning off, coordinator signal strength too low, etc), the MAC layer just has to send a disassociation notification. If the ack of the disassociation notification is not received, the device may consider itself disassociated anyway. Signed-off-by: Miquel Raynal Acked-by: Stefan Schmidt Acked-by: Alexander Aring Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-7-miquel.raynal@bootlin.com

mac802154: Handle associating

2023-11-20T10:42:39+00:00

Joining a PAN officially goes by associating with a coordinator. This coordinator may have been discovered thanks to the beacons it sent in the past. Add support to the MAC layer for these associations, which require: - Sending an association request - Receiving an association response The association response contains the association status, eventually a reason if the association was unsuccessful, and finally a short address that we should use for intra-PAN communication from now on, if we required one (which is the default, and not yet configurable). Signed-off-by: Miquel Raynal Acked-by: Stefan Schmidt Acked-by: Alexander Aring Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-5-miquel.raynal@bootlin.com