CVE-2023-53785
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-09

Last updated on: 2025-12-09

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: don't assume adequate headroom for SDIO headers mt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and mt7921_skb_add_usb_sdio_hdr(), 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 skb_cow_head() before the call to mt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to ensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE 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]: 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 After this fix, bridging the mt7921 interface works fine on both of my previously problematic systems. [1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-09
Last Modified
2025-12-09
Generated
2026-05-07
AI Q&A
2025-12-09
EPSS Evaluated
2026-05-05
NVD
CVE-2023-53785
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.1.24
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's mt76 driver for the mt7921 wireless device. The code assumes there is enough headroom in the socket buffer (skb) for SDIO headers when preparing packets for transmission. However, this assumption is not always true, especially when packets come from the receive path of another network device and are bridged to the mt7921 device. Blindly prepending bytes without ensuring sufficient headroom can cause kernel panics. The fix involves ensuring adequate headroom by calling skb_cow_head() before adding headers, preventing these panics.


How can this vulnerability impact me? :

This vulnerability can cause kernel panics (system crashes) when bridging an MT7921-based USB 802.11ax wireless interface with an Ethernet interface under certain system configurations. This can lead to system instability and potential denial of service on affected devices, such as Intel Atom-based x86 systems or ARM-based Raspberry Pi 1 devices using specific network adapters.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing kernel panics related to the mt7921 driver, especially when bridging an MT7921AU-based USB 802.11ax interface with an Ethernet interface. Look for kernel panic stack traces involving skb_push and mt7921_usb_sdio_tx_prepare_skb in your system logs (e.g., using dmesg or journalctl). Specific commands to check for such panics include: 'dmesg | grep -i mt7921', 'journalctl -k | grep -i skb_panic', or monitoring kernel logs for related errors during network bridging operations.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update your Linux kernel to a version that includes the fix where mt7921_usb_sdio_tx_prepare_skb() calls skb_cow_head() to ensure adequate headroom for SDIO headers. This fix prevents kernel panics caused by bridging MT7921 interfaces. Until the update is applied, avoid bridging the MT7921 interface with other network interfaces to prevent triggering the panic.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart