In mcr20a_handle_rx_read_buf_complete(), when
!ieee802154_is_valid_psdu_len(len) is true, the driver overwrites len
with IEEE802154_MTU (127) and copies 125 bytes from lp->rx_buf into a new
skb even though only the original len bytes were transferred over SPI,
reading past the valid RX data and leaking up to 125 bytes of stale heap
memory to the network stack:
BUG: KASAN: slab-out-of-bounds in
mcr20a_handle_rx_read_buf_complete.constprop.0+0x91/0xc0
Read of size 125 at addr ffff888002853f40 by task init/1
Call Trace:
<TASK>
dump_stack_lvl+0x70/0xa0
print_report+0x153/0x4c6
kasan_report+0xf1/0x120
kasan_check_range+0x125/0x200
__asan_memcpy+0x23/0x60
mcr20a_handle_rx_read_buf_complete.constprop.0+0x91/0xc0
...
The buggy address belongs to the object at ffff888002853f40
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes inside of
allocated 4-byte region [ffff888002853f40, ffff888002853f44)
Drop the corrupted frame, re-arm reception via mcr20a_request_rx(lp), and
return early.
Tested in QEMU with KASAN enabled by passing a corrupted 4-byte RX frame
length to mcr20a_handle_rx_read_buf_complete().
Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver
driver")
Cc: [email protected]
Assisted-by: LLM
Signed-off-by: Hui Peng <[email protected]>
---
Changes in v2:
- Split out as patch 3/4 covering only the mcr20a RX corrupted frame
handling as requested by Miquel Raynal.
drivers/net/ieee802154/mcr20a.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
index 020d392a98b6..d01b277d33d2 100644
--- a/drivers/net/ieee802154/mcr20a.c
+++ b/drivers/net/ieee802154/mcr20a.c
@@ -790,7 +790,8 @@ mcr20a_handle_rx_read_buf_complete(void *context)
if (!ieee802154_is_valid_psdu_len(len)) {
dev_vdbg(&lp->spi->dev, "corrupted frame received\n");
- len = IEEE802154_MTU;
+ mcr20a_request_rx(lp);
+ return;
}
len = len - 2; /* get rid of frame check field */
--
2.47.3
