<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/net/mac802154/scan.c, branch v6.18.22</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.22</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.22'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-09-24T09:53:50+00:00</updated>
<entry>
<title>mac802154: Fix potential RCU dereference issue in mac802154_scan_worker</title>
<updated>2024-09-24T09:53:50+00:00</updated>
<author>
<name>Jiawei Ye</name>
<email>jiawei.ye@foxmail.com</email>
</author>
<published>2024-09-24T06:58:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bff1709b3980bd7f80be6786f64cc9a9ee9e56da'/>
<id>urn:sha1:bff1709b3980bd7f80be6786f64cc9a9ee9e56da</id>
<content type='text'>
In the `mac802154_scan_worker` function, the `scan_req-&gt;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-&gt;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 &lt;jiawei.ye@foxmail.com&gt;
Acked-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Reviewed-by: Przemek Kitszel &lt;przemyslaw.kitszel@intel.com&gt;
Link: https://lore.kernel.org/tencent_3B2F4F2B4DA30FAE2F51A9634A16B3AD4908@qq.com
Signed-off-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
</content>
</entry>
<entry>
<title>mac802154: Only allow PAN controllers to process association requests</title>
<updated>2023-12-15T10:14:53+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2023-11-28T11:16:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=95d92505b6063896d7a1e6fcadd07e8552653cfb'/>
<id>urn:sha1:95d92505b6063896d7a1e6fcadd07e8552653cfb</id>
<content type='text'>
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 &lt;miquel.raynal@bootlin.com&gt;
Acked-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
Acked-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Link: https://lore.kernel.org/linux-wpan/20231128111655.507479-4-miquel.raynal@bootlin.com
</content>
</entry>
<entry>
<title>mac80254: Provide real PAN coordinator info in beacons</title>
<updated>2023-12-15T10:14:49+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2023-11-28T11:16:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cf1b830e625baaee5bf1ae4ba4b562cbec5ad012'/>
<id>urn:sha1:cf1b830e625baaee5bf1ae4ba4b562cbec5ad012</id>
<content type='text'>
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 &lt;miquel.raynal@bootlin.com&gt;
Acked-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
Acked-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Link: https://lore.kernel.org/linux-wpan/20231128111655.507479-2-miquel.raynal@bootlin.com
</content>
</entry>
<entry>
<title>mac802154: Handle disassociation notifications from peers</title>
<updated>2023-11-20T10:43:33+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2023-09-27T18:12:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1e2a45f1f854ce63c114b42298ea686dce9ae4fd'/>
<id>urn:sha1:1e2a45f1f854ce63c114b42298ea686dce9ae4fd</id>
<content type='text'>
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 &lt;miquel.raynal@bootlin.com&gt;
Acked-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
Acked-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-11-miquel.raynal@bootlin.com
</content>
</entry>
<entry>
<title>mac802154: Follow the number of associated devices</title>
<updated>2023-11-20T10:43:19+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2023-09-27T18:12:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=80f8bf9a2a7f603662e08f7663643a58087a2cd4'/>
<id>urn:sha1:80f8bf9a2a7f603662e08f7663643a58087a2cd4</id>
<content type='text'>
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 &lt;miquel.raynal@bootlin.com&gt;
Acked-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
Acked-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-10-miquel.raynal@bootlin.com
</content>
</entry>
<entry>
<title>mac802154: Handle association requests from peers</title>
<updated>2023-11-20T10:43:03+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2023-09-27T18:12:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=601f160b61b2152ef84a663f856350d5dd9e752a'/>
<id>urn:sha1:601f160b61b2152ef84a663f856350d5dd9e752a</id>
<content type='text'>
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 &lt;miquel.raynal@bootlin.com&gt;
Acked-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
Acked-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-8-miquel.raynal@bootlin.com
</content>
</entry>
<entry>
<title>mac802154: Handle disassociations</title>
<updated>2023-11-20T10:42:55+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2023-09-27T18:12:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9860d9be89f420f3793fb798faadea11c723e08a'/>
<id>urn:sha1:9860d9be89f420f3793fb798faadea11c723e08a</id>
<content type='text'>
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 &lt;miquel.raynal@bootlin.com&gt;
Acked-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
Acked-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-7-miquel.raynal@bootlin.com
</content>
</entry>
<entry>
<title>mac802154: Handle associating</title>
<updated>2023-11-20T10:42:39+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2023-09-27T18:12:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fefd19807fe9c65002366c749e809996a1ca4e68'/>
<id>urn:sha1:fefd19807fe9c65002366c749e809996a1ca4e68</id>
<content type='text'>
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 &lt;miquel.raynal@bootlin.com&gt;
Acked-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
Acked-by: Alexander Aring &lt;aahringo@redhat.com&gt;
Link: https://lore.kernel.org/linux-wpan/20230927181214.129346-5-miquel.raynal@bootlin.com
</content>
</entry>
<entry>
<title>Merge tag 'v6.4-rc4' into wpan-next/staging</title>
<updated>2023-06-06T08:42:42+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2023-06-06T08:42:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c68005083d620b1499fc81926a514d39ae8b88c'/>
<id>urn:sha1:5c68005083d620b1499fc81926a514d39ae8b88c</id>
<content type='text'>
Linux 6.4-rc4
</content>
</entry>
<entry>
<title>mac802154: Rename kfree_rcu() to kvfree_rcu_mightsleep()</title>
<updated>2023-04-05T13:48:04+00:00</updated>
<author>
<name>Joel Fernandes (Google)</name>
<email>joel@joelfernandes.org</email>
</author>
<published>2023-03-10T01:18:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eb56a4cbc3ea348dc07fbe82531c27cce83df3b9'/>
<id>urn:sha1:eb56a4cbc3ea348dc07fbe82531c27cce83df3b9</id>
<content type='text'>
The k[v]free_rcu() macro's single-argument form is deprecated.
Therefore switch to the new k[v]free_rcu_mightsleep() variant. The goal
is to avoid accidental use of the single-argument forms, which can
introduce functionality bugs in atomic contexts and latency bugs in
non-atomic contexts.

The callers are holding a mutex so the context allows blocking. Hence
using the API with a single argument will be fine, but use its new name.

There is no functionality change with this patch.

Fixes: 57588c71177f ("mac802154: Handle passive scanning")
Acked-by: Stefan Schmidt &lt;stefan@datenfreihafen.org&gt;
Reviewed-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
</content>
</entry>
</feed>
