kernel/linux.git/drivers/net/ieee802154, branch v6.6.150

ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit

2026-07-24T14:03:42+00:00

commit 6d7f7bcf225b2d566176bf6229dbd1252940cb3c upstream. ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out(). This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel address and generally results in an oops. Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture. The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs. Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers. Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Cc: stable@vger.kernel.org Signed-off-by: Shitalkumar Gandhi Reviewed-by: Simon Horman Link: https://lore.kernel.org/20260520105750.30144-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman

ieee802154: ca8210: fix cas_ctl leak on spi_async failure

2026-07-24T14:03:42+00:00

commit e09390e439bd7cca30dd10893b1f64802961667a upstream. ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC) and relies entirely on the SPI completion callback ca8210_spi_transfer_complete() to free it. The spi_async() API only invokes the completion callback on successful submission. On failure it returns a negative error code without ever queuing the callback, which leaves cas_ctl and its embedded spi_message and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is inside the completion callback, so there is no other reclamation path. ca8210_spi_transfer() is called from ca8210_spi_exchange(), the interrupt handler ca8210_interrupt_handler(), and from the retry path inside the completion callback itself. The exchange and interrupt handler paths loop on -EBUSY, so under sustained SPI bus contention every retry iteration leaks a fresh cas_ctl (~600 bytes per occurrence). Fix it by freeing cas_ctl on the spi_async() error path. While here, correct the misleading error string: the function calls spi_async(), not spi_sync(). Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Cc: stable@vger.kernel.org Signed-off-by: Shitalkumar Gandhi Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/20260421073259.2259783-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Stefan Schmidt Signed-off-by: Greg Kroah-Hartman

ieee802154: ca8210: Use proper setters and getters for bitwise types

2025-06-04T12:42:02+00:00

[ Upstream commit 169b2262205836a5d1213ff44dca2962276bece1 ] Sparse complains that the driver doesn't respect the bitwise types: drivers/net/ieee802154/ca8210.c:1796:27: warning: incorrect type in assignment (different base types) drivers/net/ieee802154/ca8210.c:1796:27: expected restricted __le16 [addressable] [assigned] [usertype] pan_id drivers/net/ieee802154/ca8210.c:1796:27: got unsigned short [usertype] drivers/net/ieee802154/ca8210.c:1801:25: warning: incorrect type in assignment (different base types) drivers/net/ieee802154/ca8210.c:1801:25: expected restricted __le16 [addressable] [assigned] [usertype] pan_id drivers/net/ieee802154/ca8210.c:1801:25: got unsigned short [usertype] drivers/net/ieee802154/ca8210.c:1928:28: warning: incorrect type in argument 3 (different base types) drivers/net/ieee802154/ca8210.c:1928:28: expected unsigned short [usertype] dst_pan_id drivers/net/ieee802154/ca8210.c:1928:28: got restricted __le16 [addressable] [usertype] pan_id Use proper setters and getters for bitwise types. Note, in accordance with [1] the protocol is little endian. Link: https://www.cascoda.com/wp-content/uploads/2018/11/CA-8210_datasheet_0418.pdf [1] Reviewed-by: Miquel Raynal Reviewed-by: Linus Walleij Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/20250305105656.2133487-2-andriy.shevchenko@linux.intel.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin

ieee802154: ca8210: Add missing check for kfifo_alloc() in ca8210_probe()

2025-01-17T12:36:11+00:00

[ Upstream commit 2c87309ea741341c6722efdf1fb3f50dd427c823 ] ca8210_test_interface_init() returns the result of kfifo_alloc(), which can be non-zero in case of an error. The caller, ca8210_probe(), should check the return value and do error-handling if it fails. Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Signed-off-by: Keisuke Nishimura Reviewed-by: Simon Horman Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/20241029182712.318271-1-keisuke.nishimura@inria.fr Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin

net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()

2024-10-10T09:57:15+00:00

[ Upstream commit 09573b1cc76e7ff8f056ab29ea1cdc152ec8c653 ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver driver") Reviewed-by: Miquel Raynal Signed-off-by: Jinjie Ruan Link: https://lore.kernel.org/20240911094234.1922418-1-ruanjinjie@huawei.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin

ieee802154: Fix build error

2024-10-10T09:57:14+00:00

[ Upstream commit addf89774e48c992316449ffab4f29c2309ebefb ] If REGMAP_SPI is m and IEEE802154_MCR20A is y, mcr20a.c:(.text+0x3ed6c5b): undefined reference to `__devm_regmap_init_spi' ld: mcr20a.c:(.text+0x3ed6cb5): undefined reference to `__devm_regmap_init_spi' Select REGMAP_SPI for IEEE802154_MCR20A to fix it. Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver driver") Signed-off-by: Jinjie Ruan Link: https://lore.kernel.org/20240909131740.1296608-1-ruanjinjie@huawei.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin

net: ieee802154: adf7242: Fix some potential buffer overflow in adf7242_stats_show()

2023-10-22T10:28:43+00:00

strncat() usage in adf7242_debugfs_init() is wrong. The size given to strncat() is the maximum number of bytes that can be written, excluding the trailing NULL. Here, the size that is passed, DNAME_INLINE_LEN, does not take into account the size of "adf7242-" that is already in the array. In order to fix it, use snprintf() instead. Fixes: 7302b9d90117 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller

ieee802154: ca8210: Fix a potential UAF in ca8210_probe

2023-10-07T18:37:38+00:00

If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock(). Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Signed-off-by: Dinghao Liu Message-ID: <20231007033049.22353-1-dinghao.liu@zju.edu.cn> Signed-off-by: Stefan Schmidt

net: Explicitly include correct DT includes

2023-07-28T03:33:16+00:00

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Acked-by: Alex Elder Reviewed-by: Bhupesh Sharma Reviewed-by: Wei Fang Signed-off-by: Rob Herring Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230727014944.3972546-1-robh@kernel.org Signed-off-by: Jakub Kicinski

Merge tag 'ieee802154-for-net-next-2023-06-23' of gitolite.kernel.org:pub/scm/linux/kernel/git/wpan/wpan-next

2023-06-24T22:41:46+00:00

Miquel Raynal says: ==================== Core WPAN changes: - Support for active scans - Support for answering BEACON_REQ - Specific MLME handling for limited devices WPAN driver changes: - ca8210: - Flag the devices as limited - Remove stray gpiod_unexport() call * tag 'ieee802154-for-net-next-2023-06-23' of gitolite.kernel.org:pub/scm/linux/kernel/git/wpan/wpan-next: ieee802154: ca8210: Remove stray gpiod_unexport() call ieee802154: ca8210: Flag the driver as being limited net: ieee802154: Handle limited devices with only datagram support mac802154: Handle received BEACON_REQ ieee802154: Add support for allowing to answer BEACON_REQ mac802154: Handle active scanning ieee802154: Add support for user active scan requests ==================== Link: https://lore.kernel.org/r/20230623195506.40b87b5f@xps-13 Signed-off-by: Jakub Kicinski