CVE-2023-53785

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7921: don&amp;#39;t assume adequate headroom for SDIO headers<br /> <br /> mt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and<br /> mt7921_skb_add_usb_sdio_hdr(), both of which blindly assume that<br /> adequate headroom will be available in the passed skb. This assumption<br /> typically is satisfied when the skb was allocated in the net core for<br /> transmission via the mt7921 netdev (although even that is only an<br /> optimization and is not strictly guaranteed), but the assumption is<br /> sometimes not satisfied when the skb originated in the receive path of<br /> another netdev and was passed through to the mt7921, such as by the<br /> bridge layer. Blindly prepending bytes to an skb is always wrong.<br /> <br /> This commit introduces a call to skb_cow_head() before the call to<br /> mt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to<br /> ensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can be<br /> pushed onto the skb.<br /> <br /> Without this fix, I can trivially cause kernel panics by bridging an<br /> MT7921AU-based USB 802.11ax interface with an Ethernet interface on an<br /> Intel Atom-based x86 system using its onboard RTL8169 PCI Ethernet<br /> adapter and also on an ARM-based Raspberry Pi 1 using its onboard<br /> SMSC9512 USB Ethernet adapter. Note that the panics do not occur in<br /> every system configuration, as they occur only if the receiving netdev<br /> leaves less headroom in its received skbs than the mt7921 needs for its<br /> SDIO headers.<br /> <br /> Here is an example stack trace of this panic on Raspberry Pi OS Lite<br /> 2023-02-21 running kernel 6.1.24+ [1]:<br /> <br /> skb_panic from skb_push+0x44/0x48<br /> skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common]<br /> mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb]<br /> mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76]<br /> __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76]<br /> mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76]<br /> mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common]<br /> mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76]<br /> __mt76_worker_fn [mt76] from kthread+0xbc/0xe0<br /> kthread from ret_from_fork+0x14/0x34<br /> <br /> After this fix, bridging the mt7921 interface works fine on both of my<br /> previously problematic systems.<br /> <br /> [1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a