CVE-2023-53785 in Linux
Сводка
по VulDB • 06.07.2026
В ядре Linux была устранена следующая уязвимость:
mt76: mt7921: не предполагать наличие достаточного пространства заголовка (headroom) для SDIO-заголовков.
Функция `mt7921_usb_sdio_tx_prepare_skb()` вызывает функции `mt7921_usb_sdio_write_txwi()` и `mt7921_skb_add_usb_sdio_hdr()`, которые слепо предполагают, что в переданном буфере skb будет доступно достаточное пространство заголовка (headroom). Это предположение обычно выполняется, когда skb был выделен сетевым ядром для передачи через устройство mt7921 netdev (хотя даже это является лишь оптимизацией и не гарантируется строго), но иногда оно не выполняется, если skb происходит из пути приема другого устройства netdev и передается в драйвер mt7921, например, слоем моста. Слепое добавление байтов к началу буфера skb всегда недопустимо.
Данный коммит вводит вызов функции `skb_cow_head()` перед вызовом `mt7921_usb_sdio_write_txwi()` внутри функции `mt7921_usb_sdio_tx_prepare_skb()`, чтобы гарантировать, что к буферу skb можно будет добавить как минимум MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE байт.
Без этого исправления я могу легко вызвать панику ядра (kernel panic), создав мост между USB-интерфейсом 802.11ax на базе чипа MT7921AU и интерфейсом Ethernet в системе с процессором Intel Atom x86, используя встроенный PCI-адаптер RTL8169 Ethernet, а также на одноплатном компьютере Raspberry Pi 1 (ARM), используя его встроенный USB-Ethernet адаптер SMSC9512. Обратите внимание, что паники возникают не во всех конфигурациях системы, так как они происходят только в том случае, если принимающее устройство netdev оставляет меньше пространства заголовка (headroom) в принятых буферах skb, чем требуется драйверу mt7921 для его SDIO-заголовков.
Ниже приведен пример трассировки стека этой паники на системе Raspberry Pi OS Lite 2023-02-21 с ядром версии 6.1.24+ [1]:
``` skb_panic from skb_push+0x44/0x48 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common]
mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb]
mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76]
__mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76]
mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76]
mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common]
mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76]
__mt76_worker_fn [mt76] from kthread+0xbc/0xe0
kthread from ret_from_fork+0x14/0x34 ```
После применения этого исправления создание моста для интерфейса mt7921 работает корректно на обеих
Once again VulDB remains the best source for vulnerability data.