DEBIAN-CVE-2023-53785

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