linux.git/net/mac802154, branch v6.11

net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD()

2024-06-03T09:20:56+00:00

mac802154 devices update their dev->stats fields locklessly. Therefore
these counters should be updated atomically. Adopt SMP safe DEV_STATS_INC()
and DEV_STATS_ADD() to achieve this.

Signed-off-by: Yunshui Jiang 
Message-ID: <20240531080739.2608969-1-jiangyunshui@kylinos.cn>
Signed-off-by: Stefan Schmidt

mac802154: fix time calculation in ieee802154_configure_durations()

2024-05-18T21:46:25+00:00

Since 'symbol_duration' of 'struct wpan_phy' is in nanoseconds but
'lifs_period' and 'sifs_period' are both in microseconds, fix time
calculation in 'ieee802154_configure_durations()' and use convenient
'NSEC_PER_USEC' in 'ieee802154_setup_wpan_phy_pib()' as well.
Compile tested only.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 781830c800dd ("net: mac802154: Set durations automatically")
Signed-off-by: Dmitry Antipov 
Acked-by: Miquel Raynal 
Message-ID: <20240508114010.219527-1-dmantipov@yandex.ru>
Signed-off-by: Stefan Schmidt

mac802154: fix llsec key resources release in mac802154_llsec_key_del

2024-03-06T20:01:26+00:00

mac802154_llsec_key_del() can free resources of a key directly without
following the RCU rules for waiting before the end of a grace period. This
may lead to use-after-free in case llsec_lookup_key() is traversing the
list of keys in parallel with a key deletion:

refcount_t: addition on 0; use-after-free.
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0
Modules linked in:
CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:refcount_warn_saturate+0x162/0x2a0
Call Trace:
 
 llsec_lookup_key.isra.0+0x890/0x9e0
 mac802154_llsec_encrypt+0x30c/0x9c0
 ieee802154_subif_start_xmit+0x24/0x1e0
 dev_hard_start_xmit+0x13e/0x690
 sch_direct_xmit+0x2ae/0xbc0
 __dev_queue_xmit+0x11dd/0x3c20
 dgram_sendmsg+0x90b/0xd60
 __sys_sendto+0x466/0x4c0
 __x64_sys_sendto+0xe0/0x1c0
 do_syscall_64+0x45/0xf0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76

Also, ieee802154_llsec_key_entry structures are not freed by
mac802154_llsec_key_del():

unreferenced object 0xffff8880613b6980 (size 64):
  comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s)
  hex dump (first 32 bytes):
    78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de  x.......".......
    00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00  ................
  backtrace:
    [] __kmem_cache_alloc_node+0x1e2/0x2d0
    [] kmalloc_trace+0x25/0xc0
    [] mac802154_llsec_key_add+0xac9/0xcf0
    [] ieee802154_add_llsec_key+0x5a/0x80
    [] nl802154_add_llsec_key+0x426/0x5b0
    [] genl_family_rcv_msg_doit+0x1fe/0x2f0
    [] genl_rcv_msg+0x531/0x7d0
    [] netlink_rcv_skb+0x169/0x440
    [] genl_rcv+0x28/0x40
    [] netlink_unicast+0x53c/0x820
    [] netlink_sendmsg+0x93b/0xe60
    [] ____sys_sendmsg+0xac5/0xca0
    [] ___sys_sendmsg+0x11d/0x1c0
    [] __sys_sendmsg+0xfa/0x1d0
    [] do_syscall_64+0x45/0xf0
    [] entry_SYSCALL_64_after_hwframe+0x6e/0x76

Handle the proper resource release in the RCU callback function
mac802154_llsec_key_del_rcu().

Note that if llsec_lookup_key() finds a key, it gets a refcount via
llsec_key_get() and locally copies key id from key_entry (which is a
list element). So it's safe to call llsec_key_put() and free the list
entry after the RCU grace period elapses.

Found by Linux Verification Center (linuxtesting.org).

Fixes: 5d637d5aabd8 ("mac802154: add llsec structures and mutators")
Cc: stable@vger.kernel.org
Signed-off-by: Fedor Pchelkin 
Acked-by: Alexander Aring 
Message-ID: <20240228163840.6667-1-pchelkin@ispras.ru>
Signed-off-by: Stefan Schmidt

mac802154: Avoid new associations while disassociating

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

While disassociating from a PAN ourselves, let's set the maximum number
of associations temporarily to zero to be sure no new device tries to
associate with us.

Signed-off-by: Miquel Raynal 
Acked-by: Stefan Schmidt 
Acked-by: Alexander Aring 
Link: https://lore.kernel.org/linux-wpan/20231128111655.507479-6-miquel.raynal@bootlin.com

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

mac802154: Use the PAN coordinator parameter when stamping packets

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

ACKs come with the source and destination address empty, this has been
clarified already. But there is something else: if the destination
address is empty but the source address is valid, it may be a way to
reach the PAN coordinator. Either the device receiving this frame is the
PAN coordinator itself and should process what it just received
(PACKET_HOST) or it is not and may, if supported, relay the packet as it
is targeted to another device in the network.

Right now we do not support relaying so the packet should be dropped in
the first place, but the stamping looks more accurate this way.

Signed-off-by: Miquel Raynal 
Acked-by: Stefan Schmidt 
Acked-by: Alexander Aring 
Link: https://lore.kernel.org/linux-wpan/20231128111655.507479-3-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