Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - mt76mt7921不假設 SDIO 標頭有足夠的空間給 SDIO 標頭 mt7921_usb_sdio_tx_prepare_skb() 呼叫 mt7921_usb_sdio_write_txwi() 和 mt7921_skb_add_usb_sdio_hdr()兩者都盲目地假設傳遞的 skb 中有足夠的空間。當 skb 是在透過 mt7921 netdev 的傳輸之網路核心中配置的 skb 時通常符合此假設 (雖然這也只是一種最佳化且並非嚴格保證)但是當 skb 源自接收路徑時有時無法符合此假設另一個 netdev 和 的 值會透過例如橋接器層傳遞到 mt7921。盲目地在 skb 前面加上位元組一律是錯誤的。此認可會在 mt7921_usb_sdio_tx_prepare_skb() 中的 mt7921_usb_sdio_write_txwi() 呼叫之前引入 skb_cow_head() 呼叫以確保至少 MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE 位元組可推送到 skb。如果沒有此修正我可以在使用其內建 RTL8169 PCI 乙太網路介面卡的 Intel Atom x86 系統上以及在 ARM 型 Raspberry Pi 1 上橋接 MT7921AU 型 USB 802.11ax 介面和乙太網路介面進而簡單地造成核心錯誤使用其內建的 SMSC9512 USB 乙太網路介面卡。請注意並非每個系統組態都會發生錯誤因為只有當接收端 netdev 在其所接收的 skbs 中留下的空餘空間少於 mt7921 針對其 SDIO 標頭所需的空間時才會發生錯誤。以下是執行核心 6.1.24+ [1] 的 skb_panic 之 skb_push+0x44/0x48 的 skb_panic 來自 mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 的 skb_push [mt7921_common] 來自 [b_sdio_t21_comare_sk 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修正橋接 mt7921 介面在我先前有問題的兩個系統上皆可正常運作。 [1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a (CVE-2023-53785)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補的弱點：CVE-2023-53785

medium Nessus Plugin ID 277888

版本 1.5