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

  - usb小工具f_ncm修正 ncm_bitrate() 中的潛在 NULL 指標解除參照。我們在 Google 內部錯誤 265639009 中我們收到了 (目前為止) 來自執行裝置 aarch64 GKI 5.10.149-android13 的無法重現的當機報告。
    AFAICT原始程式碼所在位置
    https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 呼叫堆疊為
    ncm_close() -> ncm_notify() -> ncm_do_notify()且當機發生在 ncm_do_notify+0x98/0x270 程式碼79000d0b b9000a6c f940012a f9400269 (b9405d4b) 我相信會反組合成 (我不知道 ARM 組件但它看起來很合理對我來說已經夠了...) // 假設要儲存半字 (16 位元) 到 event->wLength (在 usb_cdc_notification 結構的位移 6 處) 0B 0D 00 79 strh w11, [x8, #6] // word (32- bit) 推測儲存至 req->Length (struct usb_request 位移 8 處) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) 是從有效指標 x9 的位移 0 讀取 // IMHO 我們're讀取 'cdev->gadget' 及取得 NULL // 小工具確實位於 usb_composite_dev 結構的位移 0 2A 01 40 F9 ldr x10, [x9] // 載入 req->buf 指標其位於結構 usb_request 的位移 0 69 02 40 F9 ldr x9、[x19] // x10 為 null、當機似乎是嘗試讀取似乎對齊的 cdev->gadget->max_speed 4B 5D 40 B9 ldr w11、[x10, #0x5c]在 ncm_do_notify() 情況下 NCM_NOTIFY_SPEED 程式碼片段event->wLength = cpu_to_le16(8) req->length = NCM_STATUS_BYTECOUNT /* SPEED_CHANGE 資料加快/減慢速度 (以位元/秒為單位) */ data = req->buf + sizeof
    *事件data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));我對暫存器和 NULL 指標解除參照當機位移的分析 (無法處理虛擬位址 000000000000005c 的核心 NULL 指標解除參照)強烈建議當機是因為在執行 data[0] = cpu_to_le32(ncm_bitrate) 時 'cdev->gadget' 為 NULL (cdev->gadget))這會呼叫 ncm_bitrate(NULL) 然後會呼叫 ncm_bitrate(NULL)
    gadget_is_superspeed(NULL)其可讀取 ((struct usb_gadget *)NULL)->max_speed並造成不穩定。AFAICT如果我數數max_speed 的位移確實是 0x5C。 (請記住結構 work_struct 中有 16 位元組的 GKI KABI 保留) 我完全不清楚這應該如何運作...但是傳回 0 似乎比 panic-ing... (CVE-2023-52894)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

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

medium Nessus Plugin ID 244888

版本 1.10