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

  - devlink排清快照時保留區域鎖定 Netdevsim 在重新載入時觸發 splat當它損毀含有擱置快照的區域時警告 CPU: 1 PID: 787 at net/core/devlink.c:6291 devlink_region_snapshot_del+0x12e/0x140 CPU: 1 PID: 787 Comm: devlink Not tainted 6.1.0-07460-g7ae9888d6e1c #580 RIP: 0010:devlink_region_snapshot_del+0x12e/0x140 Call Trace: <TASK> devl_region_destroy+0x70/0x140 nsim_dev_reload_down+0x2f/0x60 [netdevsim] devlink_reload+0x1f7/0x360 devlink_nl_cmd_reload +0x6ce/0x860 genl_family_rcv_msg_doit.isra.0+0x145/0x1c0 這是 devlink_region_snapshot_del() 中的鎖定宣告我們應該在這裡保留 region->snapshot_lock。
    (CVE-2022-50712)

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

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

  - io_uring修正移除提供的緩衝區時的記憶體洩漏問題移除提供的緩衝區時並未釋放 io_buffer struct進而導致記憶體洩漏。它們無法個別釋放因為它們是按頁面大小的群組進行配置。而是必須將其新增至某些可用清單例如 io_buffers_cache。
    所有呼叫者都已持有保護它的鎖定 (損毀緩衝區時除外)因此必須在此處延伸鎖定。 (CVE-2023-54041)

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

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

  - 在 244644d 之前的 之前的 10.0 Beta.12 (即 416-beta12) 之前的 C-Kermit (即 ckermit) 允許遠端 Kermit 系統在本機系統上覆寫檔案或從本機系統擷取任意檔案。
    (CVE-2025-68920)

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

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

  - mediadvb-usb-v2gl861修正 gl861_i2c_master_xfer 中的 null-ptr-deref。在 gl861_i2c_master_xfer 中訊息由使用者控制。當 msg[i].buf 為 null 而 msg[i].len 為零時會通過之前對 msg[i].buf 的檢查。惡意資料最終到達 gl861_i2c_master_xfer。如果在沒有功能健全檢查的情況下存取 msg[i].buf[0]則會發生 null 指標解除參照。我們在 msg[i].len 上新增檢查以防止當機。類似的認可認可 0ed554fd769a (媒體dvb-usbaz6027修正 az6027_i2c_xfer() 中的 null-ptr-deref) (CVE-2023-54066)

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

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

  - usbidmouse修正 idmouse_open 中的 uninit-value。在 idmouse_create_image 中如果任何 ftip_command 失敗其會移至重設標籤。不過這會導致bulk_in_buffer[HEADER..IMGSIZE] 中的資料未初始化。並且檢查有效影像會導致未初始化的解除參照。藉由移動重設標籤前的檢查來修正此檢查只有在bulk_in_buffer[HEADER] 之後的資料具有具體資料時此檢查才有效。請注意此問題是由 KMSAN 發現因此僅測試核心編譯。 (CVE-2022-50733)

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

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

  - ALSApcm修正 PCM 記憶體配置協助程式的潛在資料爭用。PCM 記憶體配置協助程式會針對過多的緩衝區配置進行功能健全檢查。但是執行檢查時沒有適當的鎖定且不會序列化配置。這可讓使用者配置比預先定義的最大大小更多的記憶體。
    實際上這並不是什麼大問題因為它或多或少是一些作為功能健全檢查的軟限製而且不可能無限制地配置。但是最好還是解決此問題以獲得更一致的行為。修補程式涵蓋 do_alloc_pages() 中使用 card->memory_mutex 的大小檢查並增加該處配置的大小以防止進一步的溢位。當實際配置失敗時大小會相應減少。 (CVE-2023-54072)

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

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

  - staging r8712修正 _r8712_init_xmit_priv() 中的記憶體洩漏在上述常式中，記憶體是在數個位置配置的。如果第一次成功而後面的失敗則常式將會洩漏記憶體。
    此修補程式可修正認可 2865d42c78a9 (暫存r8712u將新驅動程式新增至主線核心)。r8712_xmit_resource_alloc() 中的一個潛在記憶體洩漏問題也已解決。 (CVE-2023-54001)

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

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

  - bnxt_en修正 bnxt_nvm_test() 中的記憶體洩漏問題在成功路徑中傳回之前釋放 kzalloc’ed 緩衝區。 (CVE-2022-50723)

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

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

  - RDMA/siw修正立即工作要求排清至完成佇列的問題。如果 QP 處於 ERROR 狀態，則在 post sendqueue 作業中排清立即工作要求期間正確設定傳送佇列元素 opcode。未定義的 ocode 值導致超出邊界存取針對工作完成產生中在 siw 內部與 RDMA 核心表示之間對應 opcode 的陣列。這會導致在 NFSoRDMA 測試期間產生「全域超出邊界」類型的 KASAN 錯誤報告。此修補程式可進一步修正惡意使用者可能針對完成佇列元素狀態或 opcode 寫入未定義值 (如果 CQ 是將記憶體對應至使用者平台) 的潛在案例。其可避免上述的相同超出邊界存取狀態及 opcode 對應的陣列。 (CVE-2022-50736)

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

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

  - wifimt76mt7921s修正 sdio 主機中的 slab 超出邊界存取 SDIO 可能需要額外的 511 位元組來對齊匯流排作業。如果此 skb 的 tailroom 不夠大可能會存取無效的記憶體區域。針對低階作業增加 skb 大小以在 SDIO 主機中保留有效的記憶體存取。錯誤訊息 [69.951] 錯誤KASANsg_copy_buffer+0xe9/0x1a0 中的 slab 超出邊界 [69.951] kworker/u16:7/451 工作於 addr ffff88811c9cf000 讀取大小 64 [69.951] CPU 4 PID451 通訊kworker/u16:7 污染GW OE 6.1.0-rc5 #1 [69.951] 工作佇列kvub300c vub300_cmndwork_thread [vub300] [69.951] 呼叫追踪 [69.951] ] <TASK> [69.952] dump_stack_lvl+0x49/0x63 [69.952] print_report+0x171/0x4a8 [69.952] kasan_report+0xb4/0x130 [69.952] kasan_check_range+0x149/0x1e0 [69.952] memcpy+0x24/0x70 [69.952] sg_copy_buffer+0xe9/0x1a0 [69.952] sg_copy_to_buffer+0x12/0x20 [69.952]
    __command_write_data.isra.0+0x23c/0xbf0 [vub300] [69.952] vub300_cmndwork_thread+0x17f3/0x58b0 [vub300] [69.952] process_one_work+0x7ee/0x1320 [69.952] worker_thread+0x53c/0x1240 [69.952] kthread+0x2b8/ 0x370 [69.952] ret_from_fork+0x1f/0x30 [69.952] </TASK> [69.952] 由工作 854 分配[69.952] kasan_save_stack+0x26/0x50 [69.952] kasan_set_track+0x25/0x30 [69.952] kasan_save_alloc_info+0x1b /0x30 [69.952] __kasan_kmalloc+0x87/0xa0 [69.952] __kmalloc_node_track_caller+0x63/0x150 [69.952] kmalloc_reserve+0x31/0xd0 [69.952] __alloc_skb+0xfc/0x2b0 [69.952] __mt76_mcu_msg_alloc+0xbf0/mxt69.952[  ] mt76_mcu_send_and_get_msg+0xab/0x110 [mt76] [69.952] __mt76_mcu_send_firmware.cold+0x94/0x15d [mt76] [69.952] mt76_connac_mcu_send_ram_firmware+0x415/0x54d [mt76_connac_lib] [69.952] mt76_connac2_load_ram.cold+0x118/0x4bc [ mt76_connac_lib] [69.952] mt7921_run_firmware.cold+0x2e9/0x405 [mt7921_common] [69.952] mt7921s_mcu_init+0x45/0x80 [mt7921s] [69.953] mt7921_init_work+0xe1/0x2a0 [mt7921_common] [69.953] process_one_work+0x7ee/0x1320 [69.953] worker_thread+0x53c/0x1240 [69.953] kthread+0x2b8/0x370 [69.953] ret_from_fork+0x1f/0x30 [69.953] 錯誤位址屬於 ffff88811c9ce800 處的物件該物件屬於大小為 2048 的快取 kmalloc-2k [69.953] 錯誤位址位於 2048 位元組區域右側 0 位元組 [ffff88811c9ce800, ffff88811c9cf000) [69.953] 錯誤位址周圍的記憶體狀態[69.953] ffff88811c9cef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [69.953] ffff88811c9cef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [69.953] ] >ffff88811c fc fc fc fc fc fc fc fc fc f fc fc [69.953] ^ [69.953] ffff88811c9cf080fc fc fc fc fc fc fc fc fc fc fc fc [69.953] ffff88811c9cf100fc fc fc fc fc fc fc fc fc fc fc fc fc (CVE-2022-50701)

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

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

  - net/ieee802154不在零大小的 raw_sendmsg() syzbot 在 處發出 skb_assert_len() 警告
    針對 PF_IEEE802154 通訊端的零大小 raw_sendmsg() 要求 __dev_queue_xmit() [1]
    skb->len == 0 的 __dev_queue_xmit()。由於 PF_IEEE802154 通訊端的零大小 raw_sendmsg() 要求能夠傳回 0因此如果封包長度為 0則不要呼叫 __dev_queue_xmit()。 --------- - #include<sys/socket.h> #include<netinet/in.h> int main(int argc, char *argv[]) { struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) }; struct iovec iov = { }; struct msghdr hdr = {.msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = &iov, .msg_iovlen = 1 };
    sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &hdr, 0);傳回 0 ---------- 請注意這可能表示應還原認可 fd1894224407c484 (bpf使用無效 pkt_len 重新導向封包)因為 skb->len == 0 至少可接受一段時間PF_IEEE802154 通訊端。 (CVE-2022-50706)

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

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

  - ext4修正 ext4_xattr_move_to_block() 中的無效釋放追踪。在 ext4_xattr_move_to_block() 中如果該值儲存在外部 inode 中我們需要移動到外部區塊的延伸屬性值可能會由 kvmalloc() 進行配置。因此在函式結束時程式碼會透過測試 entry->e_value_inum 來嘗試檢查是否是這種情況。不過此時 xattr 項目的指標已失效因為該指標已從儲存該指標的原始位置中移除。因此我們可能會在並非由 kvmalloc() 配置的指標上呼叫 kvfree()否則我們也可能在應該釋放緩衝區時卻不釋放緩衝區進而洩漏記憶體。將是否應在個別變數中釋放儲存以修正此問題。 (CVE-2023-54062)

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

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

  - ice修正 FDIR 的錯誤遞補邏輯。新增 FDIR 篩選器時如果 ice_vc_fdir_set_irq_ctx 傳回失敗則不會移除插入的 fdir 項目且如果 ice_vc_fdir_write_fltr 傳回失敗則不會清除 irq 處置程式的 fdir 內容資訊其可能導致不一致或記憶體洩漏問題。
    此修補程式可精簡失敗案例以解決此問題。 (CVE-2023-54040)

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

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

  - bpf修正 LRU 和 LRU_PERCPU 雜湊對應中的記憶體洩漏。LRU 和 LRU_PERCPU 對應會在鎖定目標雜湊表值區之前的更新中配置新元素。緊接著對應會嘗試鎖定該值區。如果失敗則對應將 -EBUSY 傳回至呼叫者而不釋放已配置的元素。這會使元素無法追踪它不屬於任何一個可用清單也不屬於雜湊表因此無法重複使用這最終會導致 LRU 對應更新出現非預期的永久 -ENOMEM。若儲桶鎖定失敗將元素傳回本機可用清單即可修正此問題。
    (CVE-2023-54033)

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

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

  - RDMA/核心修正 create_ah 失敗時的 GID 項目參照洩漏。如果 AH 建立要求失敗請發布 sgid_attr 以避免在發布 GID 表格時報告 GID 項目參照洩漏 (CVE-2023-54003)

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

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

  - fs保護 sb 讀寫重新組態不受爭用寫入影響。重新掛載唯讀時重新組態/重新掛載程式碼需要大量努力才能保護檔案系統的重新組態程式碼不爭用寫入。不過在將唯讀檔案系統重新掛載為讀寫模式期間一旦我們清除 SB_RDONLY 旗標便可立即開始使用者空間寫入。例如對於 ext4 來說這很不方便因為我們需要先寫入檔案系統 (例如準備配額檔案)然後才能進行使用者空間寫入所以我們要在完全準備好接受 userpace 寫入之前清除 SB_RDONLY 旗標而且 syzbot 已經找到攻擊者可利用此弱點 [1]。此外就我正在讀取程式碼而言檔案系統重新掛載的程式碼受到掛載的 MNT_READONLY 旗標保護不會在舊版掛載路徑中進行爭用寫入因此這是一個相對較新的問題。使用 sb->s_readonly_remount 旗標防止重新掛載讀寫不受爭用寫入的影響讓我們直接這麼做而不必在檔案系統程式碼中解決這些爭用情形。 [1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/ (CVE-2023-54099)

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

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

  - inotify避免報告 wd 無效的事件當 inotify_freeing_mark() 與 inotify_handle_inode_event() 爭用時發生 inotify_handle_inode_event() 發現 i_mark->wd 已重設為 -1 並將此值報告給使用者空間進而混淆 inotify 接聽程式。驗證 wd 是否合理 (並假裝在事件產生之前標記已移除)藉此避免此問題。 (CVE-2023-54119)

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

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

  - x86/xen修正 xen_init_lock_cpu() 中的記憶體洩漏在 xen_init_lock_cpu() 中@name 已由 kasprintf() 配置新字串如果 bind_ipi_to_irqhandler() 失敗應將其釋放否則可能會導致記憶體洩漏問題修正它。 (CVE-2022-50761)

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

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

  - mptcp針對 IPv6 使用適當的 req 解構函式。之前即使子流程為 IPv6也只會呼叫 IPv4 中的 TCP 要求通訊端的解構函式。請務必使用正確的解構函式以避免因某些進階 IPv6 功能而發生的記憶體洩漏例如要求 socks 包含特定 IPv6 選項時。
    (CVE-2022-50783)

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

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

  - amdgpu/pm防止 vega20_odn_edit_dpm_table() 中發生陣列反向溢位。在 PP_OD_EDIT_DDC_CURVE 情況下input_index 變數的上限為 2但並未檢查負值因此會導致超出邊界讀取。此值透過 sysfs 來自使用者。 (CVE-2022-50781)

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

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

  - 序列sc16is7xx在探查中稍後設定 GPIO 控制器sc16is7xx 驅動程式的 GPIO 控制器元件設定過早進而可能導致爭用情形在 sc16is7xx 裝置完成初始化之前另一個裝置嘗試利用 GPIO 行。已設定 GPIO 行時此問題顯示為 Oops Unable to handle kernel read from from un因素可讀記憶體的虛擬位址 ... pc sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr
    sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... 呼叫追踪
    sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138
    __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1c此修補程式會將 GPIO 控制器功能的設定移至探查功能中的稍後位置確保 sc16is7xx 裝置在其他裝置嘗試使用 GPIO 行時已完成初始化。錯誤處理也已重新排序以反映新的初始化順序。
    (CVE-2023-54118)

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

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

  - drm/amdgpu修正 amdgpu_atrm_get_bios() 中的 PCI 裝置 refcount 洩漏。如 pci_get_class() 的註解所述如果輸入參數 @from 不是 NULL其會傳回 pci_device 其 refcount 會增加而減少 refcount。如果我們以「pdev」而非 NULL 中斷 amdgpu_atrm_get_bios() 中的迴圈則需要呼叫 pci_dev_put() 以減少 refcount。新增遺漏的 pci_dev_put() 以避免 refcount 洩漏。
    (CVE-2022-50760)

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

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

  - sfc修正 NIC 進行重設時讀取統計資料時發生的當機情況可在 ethtool 自我測試期間呼叫 efx_net_stats() (.ndo_get_stats64)在此期間nic_data->mc_stats 為 NULL 因為 NIC 已結束。在此情況下請勿嘗試從硬體擷取最新的統計資料否則我們將會在發生 NULL 解除參照時當機錯誤核心 NULL 指標解除參照位址0000000000000038 RIP efx_nic_update_stats 刪減的呼叫追踪 efx_ef10_update_stats_pf efx_net_stats dev_get_stats dev_seq_printf_stats 略過讀取是安全的我們將只會提供過時的統計資料。若要確保 efx_ef10_fini_nic() 中的釋放作業不會與 efx_ef10_update_stats_pf() 發生爭用情形可造成 TOCTTOU 錯誤請採用 fini_nic 中的 efx->stats_lock (其已在整個 update_stats 中保留)。 (CVE-2023-54156)

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

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

  - audit修正 __audit_inode_child() 中可能的軟鎖定。Tracef 或 debugfs 可能造成成百上千的 PATH 記錄過多 PATH 記錄可能造成軟鎖定。例如 1. CONFIG_KASAN=y && CONFIG_PREEMPTION=n 2. auditctl -a exit,always -S open -k key 3. sysctl -w kernel.watchdog_thresh=5 4.
    mkdir /sys/kernel/debug/tracing/instances/test 可能有如下軟鎖定 watchdog 錯誤 軟鎖定 - CPU#45 停滯 7 秒[mkdir:15498] 核心錯誤 - 未同步softlockup懸置的工作呼叫追踪
    dump_backtrace+0x0/0x30c show_stack+0x20/0x30 dump_stack+0x11c/0x174 panic+0x27c/0x494 watchdog_timer_fn+0x2bc/0x390 __run_hrtimer+0x148/0x4fc __hrtimer_run_queues+0x154/0x210 hrtimer_interrupt+0x2c4/0x760 arch_timer_handler_phys+0x48/0x60 handle_percpu_devid_irq+0xe0/0x340
    __handle_domain_irq+0xbc/0x130 gic_handle_irq+0x78/0x460 el1_irq+0xb8/0x140
    __audit_inode_child+0x240/0x7bc tracefs_create_file+0x1b8/0x2a0 trace_create_file+0x18/0x50 event_create_dir+0x204/0x30c __trace_add_new_event+0xac/0x100 event_trace_add_tracer+0xa0/0x130 trace_array_create_dir+0x60/0x140 trace_array_create+0x1e0/0x370 instance_mkdir+0x90/0xd0 tracefs_syscall_mkdir+0x68/0xa0 vfs_mkdir+0x21c/0x34c do_mkdirat+0x1b4/0x1d4 __arm64_sys_mkdirat+0x4c/0x60 el0_svc_common.constprop.0+0xa8/0x240 do_el0_svc+0x8c/0xc0 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 Therefore, we add cond_resched( ) 複製到 __audit_inode_child() 以修正該問題。 (CVE-2023-54045)

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

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

  - ext4修正 ext4_mb_new_inode_pa() 中因溢位而發生的錯誤我們計算 ext4_free_extent 的結束位置時此位置可能正好是 ext4_lblk_t (即 uint) 溢位的位置。例如如果 ac_g_ex.fe_logical 是 4294965248 而 ac_orig_goal_len 是 2048則計算出的結尾是 0x100000000即 0。如果 ac->ac_o_ex.fe_logical 不是調整最佳範圍 (即 new_bex_end > 0) 的第一個案例將會觸發下列 BUG_ON =========================================== ============== fs/ext4/mballoc.c:5116! 的核心錯誤無效 opcode0000 [#1] PREEMPT SMP PTI CPU3 PID673 Comm
    xfs_io Tainted: GE 6.5.0-rc1+ #279 RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430 Call Trace: <TASK> ext4_mb_use_best_found+0x203/0x2f0 ext4_mb_try_best_found+0x163/0x240 ext4_mb_regular_allocator+0x158/0x1550 ext4_mb_new_blocks+0x86a/0xe10 ext4_ext_map_blocks+0xb0c/0x13a0 ext4_map_blocks+0x2cd/0x8f0 ext4_iomap_begin+0x27b/0x400 iomap_iter+0x222/0x3d0 __iomap_dio_rw+0x243/0xcb0 iomap_dio_rw+0x16/0x80 ========================= ================================ 示範問題的簡單複制器mkfs.ext4 -F /dev/sda -b 4096 100M mount /dev/sda /tmp/test fallocate -l1M /tmp/test/tmp fallocate -l10M /tmp/test/file fallocate -i -o 1M -l16777203M /tmp/test/file fsstress -d /tmp/test -l 0 -n 100000 -p 8 & sleep 10 && killall -9 fsstress rm -f /tmp/test/tmp xfs_io -c open -ad /tmp/test/file -c pwrite -S 0xff 0 8192 我們只是重構透過新增暫時 ext4_free_extent 來調整最佳範圍的邏輯 ex 並使用 extent_logical_end() 來避免溢位同時也簡化了程式碼。 (CVE-2023-54069)

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

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

  - net/mlx5修正 async 命令介面中可能的釋放後使用錯誤 mlx5_cmd_cleanup_async_ctx 應該只在其所有回呼處置程式完成之後傳回。在此修補程式之前mlx5_cmd_cleanup_async_ctx 和 mlx5_cmd_exec_cb_handler 之間可能發生下列爭用且會導致釋放後使用1。
    當 num_inflight 為 2 時呼叫 mlx5_cmd_cleanup_async_ctx (即提升 1、單一傳送回呼)。 2. mlx5_cmd_cleanup_async_ctx 將 num_inflight 降低至 1。 3. 呼叫 mlx5_cmd_exec_cb_handler將 num_inflight 降低至 0且即將呼叫 wake_up()。 4. mlx5_cmd_cleanup_async_ctx 呼叫 wait_event在條件 (num_inflight == 0) 成立時立即傳回。 5.
    mlx5_cmd_cleanup_async_ctx 傳回。 6. mlx5_cmd_cleanup_async_ctx 的呼叫者釋放 mlx5_async_ctx 物件。 7. mlx5_cmd_exec_cb_handler 繼續呼叫已釋放物件上的 wake_up()。透過使用完成物件同步來修正此問題。當 num_inflight 達到 0 時將其標記為完成。追踪錯誤 KASAN在 do_raw_spin_lock+0x23d/0x270 讀取 addr ffff888139cd12f4 的大小 4 中 (由工作 swapper/5/0 CPU: 5 PID: 0 Commswapper/5)未受污染 6.0.0-rc3_for_upstream_debug_2022_08_30_13_10 #1 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 呼叫追踪
    <IRQ> dump_stack_lvl+0x57/0x7d print_report.cold+0x2d5/0x684 do_raw_spin_lock+0x23d/0x270 kasan_report+0xb1/0x1a0 ? do_raw_spin_lock+0x23d/0x270 do_raw_spin_lock+0x23d/0x270 ? rwlock_bug.part.0+0x90/0x90 ? __delete_object+0xb8/0x100 ? lock_downgrade+0x6e0/0x6e0
    _raw_spin_lock_irqsave+0x43/0x60 ? __wake_up_common_lock+0xb9/0x140 __wake_up_common_lock+0xb9/0x140 ?
    __wake_up_common+0x650/0x650 ? destroy_tis_callback+0x53/0x70 [mlx5_core] kasan_set_track+0x21/0x30 destroy_tis_callback+0x53/0x70 [mlx5_core] kfree+0x1ba/0x520 ? do_raw_spin_unlock+0x54/0x220 mlx5_cmd_exec_cb_handler+0x136/0x1a0 [mlx5_core] mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core] mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core] mlx5_cmd_comp_handler+0x65a/0x12b0 [mlx5_core] dump_command+0xcc0/0xcc0 [mlx5_core] ? lockdep_hardirqs_on_prepare+0x400/0x400 ? cmd_comp_notifier+0x7e/0xb0 [mlx5_core] cmd_comp_notifier+0x7e/0xb0 [mlx5_core] atomic_notifier_call_chain+0xd7/0x1d0 mlx5_eq_async_int+0x3ce/0xa20 [mlx5_core] atomic_notifier_call_chain+0xd7/0x1d0 ? irq_release+0x140/0x140 [mlx5_core] irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x1f2/0x620 handle_irq_event+0xb2/0x1d0 handle_edge_irq+0x21e/0xb00
    __common_interrupt+0x79/0x1a0 common_interrupt+0x78/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 RIP
    0010:default_idle+0x42/0x60 程式碼c1 83 e0 07 48 c1 e9 03 83 c0 03 0f b6 14 11 38 d0 7c 04 84 d2 75 14 8b 05 eb 47 22 02 85 c0 7e 07 0b 4800 2d e0 9f <c3> f4  48 c7 c7 80 08 7f 85 e8 d1 d3 3e fe eb de 66 66 2e 0f 1f 84 00 RSP: 0018:ffff888100dbfdf0 EFLAGS: 00000242 RAX: 0000000000000001 RBX: ffffffff84ecbd48 RCX: 1ffffffff0afe110 RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff835cc9bc RBP
     R080000000000000005  : 0000000000000001 R09: ffff88881dec4ac3 R10: ffffed1103bd8958 R11: 0000017d0ca571c9 R12: 0000000000000005 R13: ffffffff84f024e0 R14: 0000000000000000 R15: dffffc0000000000 ? default_idle_call+0xcc/0x450 default_idle_call+0xec/0x450 do_idle+0x394/0x450 ? arch_cpu_idle_exit+0x40/0x40 ? do_idle+0x17/0x450 cpu_startup_entry+0x19/0x20 start_secondary+0x221/0x2b0 ? set_cpu_sibling_map+0x2070/0x2070 secondary_startup_64_no_verify+0xcd/0xdb </TASK> Allocated by task 49502: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 kvmalloc_node+0x48/0xe0 mlx5e_bulk_async_init+0x35/0x110 [mlx5_core] mlx5e_tls_priv_tx_list_cleanup+0x84/0x3e0 [mlx5_core] mlx5e_ktls_cleanup_tx+ 0x38f/0x760 [mlx5_core] mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core] mlx5e_detach_netdev+0x1c ---truncated--- (CVE-2022-50726)

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

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

  - wifimt76mt7921修正因 AMSDU 中遺漏 txs 的 skb 洩漏 txs 可能在 AMSDU 中匯總框架時遭到捨棄的問題。當問題出現時部分 SKB 會保留在驅動程式中造成網路暫時停止。
    即使問題可以透過 txs 逾時處理來復原mt7921 仍需要停用 AMSDU 中的 txs 以避免此問題。 (CVE-2023-54052)

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

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

  - rcu修正 rcu_force_quiescent_state() 中的 __this_cpu_read() lockdep 警告。在以 CONFIG_PREEMPTION=y 構建的核心中執行含有非零 fqs_duration 模組參數的 rcutorture 時會導致下列錯誤
    錯誤在搶占式中使用 __this_cpu_read() [00000000] 程式碼rcu_torture_fqs/398 呼叫端為
    __this_cpu_preempt_check+0x13/0x20 CPU3 PID398 通訊rcu_torture_fqs 未受污染 6.0.0-rc1-yoctodev-standard+ 呼叫追踪 <TASK> dump_stack_lvl+0x5b/0x86 dump_stack+0x10/0x16 check_preemption_disabled+0xe5/0xf0 __this_3/cpux20preempt_check+0x1 rcu_force_quiescent_state.part.0+0x1c/0x170 rcu_force_quiescent_state+0x1e/0x30 rcu_torture_fqs+0xca/0x160 rcu_torture_boost+0x430/0x430 kthread+0x192/0x1d0 ? kthread_complete_and_exit+0x30/0x30 ret_from_fork+0x22/0x30 </TASK> 問題是 rcu_force_quiescent_state() 在搶占式程式碼中使用 __this_cpu_read() 而非正確的 raw_cpu_read()。因此此認可會將 __this_cpu_read() 變更為 raw_cpu_read()。 (CVE-2022-50771)

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

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

  - fs放置命名空間鎖定下的對等群組 ID 清理失敗路徑中的對等群組 ID 時我們必須確保保留命名空間鎖定。否則其他執行緒可能會同時將共用掛載變成非共用掛載。 (CVE-2023-54128)

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

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

  - powerpc/iommu修正 PCI 和 VIO 匯流排共用的通知程式 fail_iommu_setup() 將 fail_iommu_bus_notifier 結構註冊到 PCI 和 VIO 匯流排。結構 notifier_block 是連結清單節點因此這會造成之後註冊至任一匯流排類型的通知程式也註冊至另一個因為它們共用相同節點。這會造成 (至少) vgaarb 程式碼發生問題該程式碼會註冊 PCI 匯流排的通知程式。 pci_notify() 最終會在 vio 裝置上遭到呼叫以 to_pci_dev() 轉換 (即使它不是 PCI 裝置)最後在 vga_arbiter_add_pci_device() 中進行不良存取如同透過 KASAN 所發現的
    BUG: KASAN由 task swapper/0/1 呼叫追踪 dump_stack_lvl+0x1bc/0x2b8 (不可靠) print_report+0x3f4/0xc60 kasan_report+0x244在 addr c000000264c26fdc 讀取大小 4 的 vga_arbiter_add_pci_device+0x60/0xe00 中發生平台超出邊界問題/0x698 __asan_load4+0xe8/0x250 vga_arbiter_add_pci_device+0x60/0xe00 pci_notify+0x88/0x444 notifier_call_chain+0x104/0x320 blocking_notifier_call_chain+0xa0/0x140 device_add+0xac8/0x1d30 device_register+0x58/0x80 vio_register_device_node+0x9ac/0xce0 vio_bus_scan_register_devices+0xc4/0x13c
    __machine_initcall_pseries_vio_device_init+0x94/0xf0 do_one_initcall+0x12c/0xaa8 kernel_init_freeable+0xa48/0xba8 kernel_init+0x64/0x400 ret_from_kernel_thread+0x5c/0x64 透過為每個匯流排類型建立獨立的 notifier_block 結構來修正此問題。 [mpe新增 #ifdef 以修正 CONFIG_IBMVIO=n 版本] (CVE-2023-54095)

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

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

  - scsi: qedi修正 qedi_remove() 中的釋放後使用錯誤。在 qedi_probe() 中我們呼叫了 __qedi_probe()它會以 qedi_recovery_handler() 初始化 &qedi->recovery_work並用 qedi_board_disable_work() 初始化 &qedi->board_disable_work。呼叫 qedi_schedule_recovery_handler() 時schedule_delayed_work() 最終會開始工作。在 qedi_remove() (系統會呼叫移除驅動程式) 中可能會觀察到下列序列情形完成 qedi_remove() 中的清理前的工作以修正此問題。CPU0 CPU1 |qedi_recovery_handler qedi_remove | qedi_recovery_handler __qedi_remove | __qedi_remove iscsi_host_free | scsi_host_put | //釋放 shost |iscsi_host_for_each_session |//use qedi->shost 取消 中的 recovery_work 和 board_disable_work
    __qedi_remove()。 (CVE-2023-54100)

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

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

  - s390/dcssblk修正因 list_add 損毀 Commit fb08a1908cb1 (dax: Simplified the dax_device <-> gendisk Association) 引入的 gendisk 關聯新邏輯要求驅動程式明確呼叫 dax_add_host() 和 dax_remove_host() 時發生的核心損毀。針對 dcssblk 驅動程式例如裝置移除路徑中遺漏一些 dax_remove_host() 呼叫。此認可也會中斷裝置新增路徑中 out_dax 案例的錯誤處理進而導致在該案例中產生額外的 put_device() (不含先前的 get_device())。這會導致在裝置新增/移除週期之後xarray 項目過時。若先前使用過的 struct gendisk 指標 (xarray 索引) 將再次使用時因為 blk_alloc_disk() 剛好傳回此類指標dax_add_host() 中的 xa_insert() 會失敗並前往 out_dax執行額外的 put_device( )。再結合 dcssblk (device_register() 清理) 中已經有瑕疵的錯誤處理 (device_register() 清理) (必須在個別的修補程式中加以解決)這會導致 device_del() / klist_del() 遺漏並最終導致核心上的 list_add 損毀而損毀後續的 device_add() / klist_add()。可透過新增遺漏的 dax_remove_host() 呼叫來修正此問題此外還可移動錯誤路徑中的 put_device() 以還原之前的邏輯。 (CVE-2023-54117)

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

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

  - virtio_pmem為排清 bio 新增缺少的 REQ_OP_WRITE 在 pmem 裝置上執行 mkfs.xfs 時下列警告為 ------------[cut here ]---------- -- 警告 CPU2 PID384@block/blk-core.c:751 submit_bio_noacct 連結的模組CPU2 PID 384 通訊mkfs.xfs 未受污染的 6.4.0-rc7+ #154 硬體名稱QEMU 標準PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... 呼叫追踪 <TASK> ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60 根本原因是submit_bio_noacct() 需要 bio_op() 為 WRITE 或 ZONE_APPEND 才能排清 bio 而 async_pmem_flush() 並不會在配置排清 bio 時指派 REQ_OP_WRITE因此 submit_bio_noacct 只會讓排清 bio 失敗。只需新增排清 bio 遺漏的 REQ_OP_WRITE 即可修正。我們可以修正排清順序問題稍後再進行排清最佳化。 (CVE-2023-54089)

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

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

  - wifi: rt2x00: 修正處理調查時發生的記憶體洩漏。移除 rt2x00 裝置時其相關聯的通道調查並未釋放進而造成可透過 kmemleak觀察到的記憶體洩漏未參照物件 0xffff9620f0881a00 (大小 512)comm systemd-udevd、pid 2290、jiffies 4294906974 (33.768s) 十六進位轉儲存 (前 32 個位元組)70 44 12 00 00 00 00 92 8a 00 00 00 00 00 00 pD........ 00 00 00 00 00 00 00 00 ab 87 01 00 00 00 00 00 ........ 反向追踪 [<ffffffffb0ed858b>] __kmalloc+0x4b/0x130 [<ffffffffc1b0f29b>] rt2800_probe_hw+0xc2b/0x1380 [rt2800lib] [<ffffffffc1a9496e>] rt2800usb_probe_hw+0xe/0x60 [rt2800usb] [<ffffffffc1ae491a>] rt2x00lib_probe_dev+0x21a/0x7d0 [rt2x00lib] [<ffffffffc1b3b83e>] rt2x00usb_probe+0x1be/0x980 [rt2x00usb] [<ffffffffc05981e2>] ] usb_probe_interface+0e [2 [/0310] [usbxcore<ffffffffb13be2d5>] ] ] real_probe+0x1a5/0x410 [<ffffffffb13be5c8>] __driver_probe_device+0x78/0x180 [<ffffffffb13be6fe>] driver_probe_device+0x1e/0x90 [<ffffffffb13be972>] __driver_attach+0xd2/0x1c0 [<ffffffffb13bbc57>] bus_for_each_dev+0x77/0xd0 [<ffffffffb13bd2a2>] bus_add_driver+0x112 /0x210 [<ffffffffb13bfc6c>] driver_register+0x5c/0x120 [<ffffffffc0596ae8>] usb_register_drive r+0x88/0x150 [usbcore] [<ffffffffb0c011c4>] do_one_initcall+0x44/0x220 [<ffffffffb0d6134c>] do_init_module+0x4c/0x220 移除裝置時釋放通道調查藉此修正此問題。已使用 RT3070 型的 USB 無線介面卡測試。 (CVE-2023-54131)

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

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

  - s390/lcs修正 lcs_start_xmit() 的傳回類型 透過 clang 的核心控制流程完整性 (kCFI、CONFIG_CFI_CLANG)間接呼叫目標會根據預期的函式指標原型進行驗證以確保呼叫目標有效有助於減輕 ROP 攻擊。如果不相同則會在執行時發生失敗其表現形式為核心錯誤或執行緒遭到終止。clang 中的一個建議警告旨在於編譯時擷取這些警告其會顯示 drivers/s390/net/lcs.c:2090:21錯誤
    使用 'int (struct sk_buff * 、struct net_device *)」 [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit^~~~~~~ ~ ~ ~ ~~ drivers/s390/net/lcs.c 2097:21錯誤不相容的函式指標類型正在使用 類型的運算式初始化 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (即 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit、^~ ~ ~ ~ ~ ~ ~ ~
    ->struct net_device_ops 中的 ndo_start_xmit() 預期傳回類型為「netdev_tx_t」而非「int」。調整 lcs_start_xmit() 的傳回類型以符合原型的 以解決警告和潛在的 CFI 失敗 (若 s390 日後選取 ARCH_SUPPORTS_CFI_CLANG)。 (CVE-2022-50728)

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

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

  - wifirtw88使用工作更新速率以避免 RCU 警告ieee80211_ops::sta_rc_update 必須為不可部分完成因為 ieee80211_chan_bw_change() 會在呼叫 drv_sta_rc_update() 時保留 rcu_read 鎖定因此請建立工作以執行原始項目。RCU 讀取端重要區段內的自動內容切換警告 CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x571/0x5d0 CPU: 0 PID: 4621 Comm
    kworker/u16:2 受污染GW OE 工作佇列phy3 ieee80211_chswitch_work [mac80211] RIP
    0010rcu_note_context_switch+0x571/0x5d0 呼叫追踪 <TASK> __schedule+0xb0/0x1460
    __mod_timer+0x116/0x360 schedule+0x5a/0xc0 schedule_timeout+0x87/0x150 ? trace_raw_output_tick_stop+0x60/0x60 wait_for_completion_timeout+0x7b/0x140 usb_start_wait_urb+0x82/0x160 [usbcore usb_control_msg+0xe3/0x140 [usbcore rtw_usb_read+0x88/0xe0 [rtw_usb rtw_usb_read8+0xf/0x10 [rtw_usb rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core drv_sta_rc_update+0x7c/0x160 [mac80211 ieee80211_chan_bw_change+0xfb/0x110 [mac80211 ieee80211_change_chanctx+0x38/0x130 [mac80211 ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211 ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211 ieee80211_chswitch_work+0x95/0x170 [mac80211 process_one_work+0x201/0x410 worker_thread +0x4a/0x3b0 ? process_one_work+0x410/0x410 kthread+0xe1/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> (CVE-2023-54071)

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

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

  - usbrndis_host針對 int 溢位進行安全 rndis_query 檢查。在 rndis_query 函式中輸入為 uint32 的變數 off 和 len 受到傳入的 RNDIS 回應訊息控制因此其值可能遭到操控。將 off 設定為超乎預期的大值會造成 len 與 8 的總和溢位並通過已實作的驗證步驟。因此回應指標會參照超出預期緩衝區邊界的位置進而允許資訊洩漏例如透過 RNDIS_OID_802_3_PERMANENT_ADDRESS OID。 (CVE-2023-54110)

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

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

  - igb啟用 SR-IOV 時清理所有錯誤路徑中的max_vfs 參數設定為某個值!= 0。如果測試機器具有雙連接埠 82580會發生以下懸置[ 232.480687] igb 0000:41:00.1移除 enp65s0f1 上的 PHC [ 233.093257] igb 0000:41 00.1IOV 已停用 [ 233.329969] pcieport 0000:40:01.0: AER多個未更正 (非嚴重) err0 [ 233.340302] igb 0000:41:00.0PCIe 匯流排錯誤severity=Uncorrected (非嚴重) [ 233.352248] igb 0000:41:00.0: 裝置 [8086:1516] 錯誤狀態/mask=00100000 [ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First) [ 233.368183] igb 0000:41:00.0: AER TLP 標頭40000001 0000040f cdbfc00c c [ 233.376846] igb 0000:41:00.1: PCIe 匯流排錯誤severity=Uncorrected (Non-Fata) [ 233.388779] igb 0000:41:00.1: device [8086:1516] 錯誤狀態/mask=00100000 [ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First) [ 233.404736] igb 0000:41:00.1: AER: TLP 標頭40000001 0000040f cdbfc00c c [ 233.538214] pci 0000:41:00.1: AER無法復原 (無 error_detected 回呼) [ 233.538401] igb 0000:41:00.0已移除 enp65s0f0 上的 PHC [233.546197] pcieport 0000:40:01.0: AERdevice復原失敗 [ 234.157244] igb 0000:41:00.0IOV 已停用 [ 371.619705] 資訊工作 irq/35-aerdrv:257 遭封鎖超過 122 秒。 [ 371.627489] 未受污染的 6.4.0-dirty #2 [ 371.632257] echo 0 > /proc/sys/kernel/hung_task_timeout_secs 會停用此功能。 [371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0 [ 371.650330] 呼叫追踪[ 371.653061] <TASK> [ 371.655407] __schedule+0x20e/0x660 [ 371.659313] schedule+0x5a/0xd0 [ 371.662824] schedule_preempt_disabled+0x11/0x20 [ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0 [ 371.673237] ?
    __pfx_aer_root_reset+0x10/0x10 [ 371.678105] report_error_detected+0x25/0x1c0 [ 371.682974] ?
    __pfx_report_normal_detected+0x10/0x10 [ 371.688618] pci_walk_bus+0x72/0x90 [ 371.692519] pcie_do_recovery+0xb2/0x330 [ 371.696899] aer_process_err_devices+0x117/0x170 [ 371.702055] aer_isr+0x1c0/0x1e0 [ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0 [ 371.710723]
    __pfx_irq_thread_fn+0x10/0x10 [ 371.715496] irq_thread_fn+0x20/0x60 [ 371.719491] irq_thread+0xe6/0x1b0 [371.723291] ? __pfx_irq_thread_dtor+0x10/0x10 [ 371.728255] ? __pfx_irq_thread+0x10/0x10 [ 371.732731] kthread+0xe2/0x110 [ 371.736243] __pfx_kthread+0x10/0x10 [ 371.740430] ret_from_fork+0x2c/0x50 [371.744428</TASK> ] 複製器是簡單的指令碼#!/bin/sh for i in `seq 1 5` do modprobe -rv igb modprobe -v igb max_vfs=1 sleep 1 modprobe -rv igb done 此問題只能在 82580 (四通道和雙連接埠) 上複製而不能在 82576、i350 和 i210 上。進一步除錯顯示 igb_enable_sriov() 對 pci_enable_sriov() 的呼叫失敗這是因為 82580 上的 dev->is_physfn 為 0。在認可 50f303496d92 (igb在 reinit 後啟用 SR-IOV)之前igb_enable_sriov() 會跳入 err_out 清理分支。在此認可之後只會傳回錯誤碼。因此並未發生清理且 igb_adapter 結構中錯誤的 VF 設定誘騙 igb 驅動程式假設已在實際不存在 VF 的地方設定 VF。如果 pci_enable_sriov() 失敗請再次清理以修正此問題。
    (CVE-2023-54070)

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

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

  - vhost-vdpa修正 iotlb 記憶體洩漏。在認可 3d5698793897 之前 (vhost-vdpa 引入 asid 型 IOTLB)我們在發布期間呼叫了 vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1)以釋放在處理使用者 IOTLB 訊息時配置的所有資源至 vhost_vdpa_process_iotlb_update()。該認可稍微變更了 IOTLB 的處理方式且我們不小心移除了版本發布期間所呼叫的部分程式碼。我們透過提交 037d4305569a 修正了部分此問題 (vhost-vdpa在釋出期間呼叫 vhost_vdpa_cleanup)但潛在的記憶體洩漏問題仍然存在如 kmemleak 所示應用程式未傳送 VHOST_IOTLB_INVALIDATE 或當機未參照物件 0xffff888007fbaa30 (大小 16)comm blkio -bench、pid 914、jiffies 4294993521 (885.500s 時效) 十六進位轉儲存 (前 16 個位元組)40 73 41 07 80 88 ff ff 00 00 00 00 00 00 00 00 @sA....... .. 反向追踪 [<0000000087736d2a>] kmem_cache_alloc_trace+0x142/0x1c0 [<0000000060740f50>] vhost_vdpa_process_iotlb_msg+0x68c/0x901 [vhost_vdpa] [<0000000083e8e205>] vhost_chr_write_iter+0xc0/0x4a0 [vhost] [<000000008f2f414a>] vhost_vdpa_chr_write_iter_vdpa] [/0x20 [vhost]<00000000de1cd4a0>] vfs_write+0x216/0x4b0 [<00000000a2850200>] ksys_write+0x71/0xf0 [<00000000de8e720b>] __x64_sys_write+0x19/0x20 [<0000000018b12cbb>] do_syscall_64+0x3f/0x90 [<00000000986ec465>] entry_SYSCALL_64_after_hwframe+0x63/0xcd讓我們修正此呼叫 vhost_vdpa_iottlbun_map ) 在 vhost_vdpa_remove_as() 中的整個範圍內。由於我們需要 vhost_vdpa_pa_unmap() 中的有效 v->vdev.mm因此將該呼叫移至 vhost_dev_cleanup() 之前。可移除 vhost_iotlb_reset() 呼叫因為整個範圍上的 vhost_vdpa_iotlb_unmap() 會移除所有項目。使用「use_va」設為 true (例如 VDUSE) 的 vDPA 裝置時觀察到所報告的 kmemleak 記錄。此修補程式已在這兩種類型的裝置上進行測試。 (CVE-2022-50738)

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

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

  - ALSAfirewire-digi00x防止可能的釋放後使用。如果 init_stream() 失敗此程式碼應該會傳回錯誤碼但它反而會釋放 dg00x->rx_stream 並傳回成功。這可能會導致釋放後使用。 (CVE-2023-54084)

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

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

  - md/raid10修正「conf->bio_split」的記憶體洩漏。在 raid10_run() 的錯誤路徑中「conf」必須釋出但是遺漏「conf->bio_split」且記憶體將會洩漏。由於有 3 個位置可釋放「conf」因此分解出協助程式來修正問題。 (CVE-2023-54123)

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

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

  - dmaengineqcom-adm修正 prep_slave_sg 的錯誤呼叫慣例pre_slave_sg 的呼叫慣例會在發生錯誤時傳回 NULL 並提供錯誤記錄給系統。發生錯誤時Qcom-adm 改為提供錯誤指標。例如對於僅在 device_prep_slave_sg 傳回的指標不是 NULL 時檢查的 nandc 驅動程式這會間接造成核心錯誤。傳回錯誤指標會使 nandc 認為 device_prep_slave_sg 函式已正確完成並在稍後的程式碼中造成核心錯誤。雖然是 nandc 造成核心當機但仍指出真正的問題在於 qcom-adm 並未遵循該函式的呼叫慣例。若要修正此問題請中斷傳回錯誤指標並以錯誤記錄傳回 NULL。 (CVE-2022-50721)

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

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

  - soundwire修正列舉完成 soundwire 子系統使用兩個完成結構會允許驅動程式分別等待 soundwire 裝置在匯流排上變成列舉狀態以及由其驅動程式初始化。實作訊號的程式碼目前已損毀因為它不會向所有目前和未來的等候者發出訊號並且使用錯誤的重新初始化函式如果佇列上還有等候者則可能導致記憶體損毀。未特別發出未來等候者的訊號中斷音效卡探查延遲因為轉碼器驅動程式無法判斷 soundwire 裝置在重新探查時是否已連接。部分轉碼器運行時間 PM 實作受到類似問題影響因為即使裝置已列舉在恢復期間等候列舉也可能逾時。
    (CVE-2023-54096)

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

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

  - net/mlx5e將表示器鄰居清理移至設定檔 cleanup_tx針對 ECMP (等價多路徑) 模式中的 IP 通道封裝流量複製到對等 eswitch 時也會在對等節點上傳鏈路表示器上建立相關鄰居資訊。在引用的提交中eswitch devcom unpair 已移至上傳連結卸載 API具體而言是 profile->cleanup_tx。如果在 ECMP 模式下卸載了 encap 規則則當有一個 eswitch 取消配對 (例如因為卸載驅動程式)且來自對等 eswitch 的對等規則即將遭到刪除時就會觸發釋放後使用錯誤存取 neigh 資訊時因為其已在 uplink 的 profile->disable 中清除而其位於其 profile->cleanup_tx 之前。
    若要修正此問題請將 neigh 清理移至設定檔的 cleanup_tx 回呼並在呼叫 mlx5e_cleanup_uplink_rep_tx 之後進行。neigh init 移至 init_txfor symmeter。 [ 2453.376299] 錯誤KASANmlx5e_rep_neigh_entry_release+0x109/0x3a0 中的 slab 釋放後使用 [mlx5_core] [ 2453.379125] 工作 modprobe/2496 在 addr ffff888127af9008 讀取大小 4 [ 2453.381542] CPU7 PID2496 Comm
    modprobe 污染GB 6.4.0-rc7+ #15 [ 2453.383386] 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/ 2014 [ 2453.384335] 呼叫追踪 [ 2453.384625] <TASK> [ 2453.384891] dump_stack_lvl+0x33/0x50 [ 2453.385285] print_report+0xc2/0x610 [ 2453.385667] ?
    __virt_addr_valid+0xb1/0x130 [ 2453.386091] mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core] [2453.386757] kasan_report+0xae/0xe0 [ 2453.387123] mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core] [ 2453.387798] mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core] [ 2453.388465] mlx5e_rep_encap_entry_detach+0xa6/0xe0 [mlx5_core] [ 2453.389111] mlx5e_encap_dealloc+0xa7/0x100 [mlx5_core] [ 2453.389706] mlx5e_tc_tun_encap_dests_unset+ 0x61/0xb0 [mlx5_core] [ 2453.390361] mlx5_free_flow_attr_actions+0x11e/0x340 [mlx5_core] [ 2453.391015] ? complete_all+0x43/0xd0 [ 2453.391398] ? free_flow_post_acts+0x38/0x120 [mlx5_core] [ 2453.392004] mlx5e_tc_del_fdb_flow+0x4ae/0x690 [mlx5_core] [ 2453.392618] mlx5e_tc_del_fdb_peers_flow+0x308/0x370 [mlx5_core] [ 2453.393276] mlx5e_tc_clean_fdb_peer_flows+0xf5/0x140 [mlx5_core] [ 2453.393925] mlx5_esw_offloads_unpair+ 0x86/0x540 [mlx5_core] [ 2453.394546] ? mlx5_esw_offloads_set_ns_peer.isra.0+0x180/0x180 [mlx5_core] [ 2453.395268] down_write+0xaa/0x100 [ 2453.395652] mlx5_esw_offloads_devcom_event+0x203/0x530 [mlx5_core] [ 2453.396317] mlx5_devcom_send_event+0xbb/0x190 [mlx5_core] [ 2453.396917] mlx5_esw_offloads_devcom_cleanup+0xb0/0xd0 [mlx5_core] [ 2453.397582] mlx5e_tc_esw_cleanup+0x42/0x120 [mlx5_core] [ 2453.398182] mlx5e_rep_tc_cleanup+0x15/0x30 [mlx5_core] [ 2453.398768] mlx5e_cleanup_rep_tx+0x6c/0x80 [mlx5_core] [2453.399367] mlx5e_detach_netdev+0xee/0x120 [mlx5_core] [ 2453.399957] mlx5e_netdev_change_profile+50_core84/0x170 [mlx5e_detach_netdev+0xee/0x120] ] [ 2453.400598] mlx5e_vport_rep_unload+0xe0/0xf0 [mlx5_core] [ 2453.403781] mlx5_eswitch_unregister_vport_reps+0x15e/0x190 [mlx5_core] [ 2453.404479] ? mlx5_eswitch_register_vport_reps+0x200/0x200 [mlx5_core] [ 2453.405170] ? up_write+0x39/0x60 [2453.405529] ? kernfs_remove_by_name_ns+0xb7/0xe0 [ 2453.405985] mandatory_bus_remove+0x2e/0x40 [2453.406405] device_release_driver_internal+0x243/0x2d0 [ 2453.406900] ? kobject_put+0x42/0x2d0 [2453.407284] bus_remove_device+0x128/0x1d0 [ 2453.407687] device_del+0x240/0x550 [ 2453.408053] ? waiting_for_supplier_show+0xe0/0xe0 [ 2453.408511] ? kobject_put+0xfa/0x2d0 [ 2453.408889] ?
    __kmem_cache_free+0x14d/0x280 [ 2453.409310] mlx5_rescan_drivers_locked.part.0+0xcd/0x2b0 [mlx5_core] [2453.409973] mlx5_unregister_device+0x40/0x50 [mlx5_core] [ 2453.410561] ] mlx5_uninit_one+0x3d/0x110 [mlx5_core] [ 2453.411111] removeone_ +0x89/0x130 [mlx5_core] [ 24 ---truncated--- (CVE-2023-54148)

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

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

  - md/raid1當我們僅在 raid1 陣列執行失敗時停止 mdx_raid1 執行緒當我們用停用的磁碟組合陣列但 mdx_raid1 執行緒並未停止時即使已釋放相關聯的資源仍會執行 raid1。當我們關閉電源時會造成 NULL 解除參照。這會造成下列 Oops[287.587787] 錯誤核心 NULL 指標解除參照、位址0000000000000070 [ 287.594762] #PF核心模式中的監督讀取存取 [ 287.599912] #PFerror_code(0x0000) - 不存在頁面 [ 287.605061] PGD 0 P4D 0 [ 287.607612] Oops0000 [#1] SMP NOPTI [ 287.611287] CPU3 PID 5265 通訊md0_raid1 污染GU 5.10.146 #0 [ 287.619029] 硬體名稱 xxxxxxx/待填依據 OEM、BIOS 5.19 2022 年 6 月 16 日 [ 287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod] [ 287.632357] 程式碼fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89。 ..... [ 287.651118] RSP0018:ffffc90000433d78 EFLAGS00010202 [ 287.656347] RAX
    0000000000000000 RBXffff888105986800 RCX 0000000000000000 [ 287.663491] RDXffffc90000433bb0 RSI
    00000000ffffefff RDIffff888105986800 [ 287.670634] RBP ffffc90000433da0 R080000000000000000 R09
    c0000000ffffefff [ 287.677771] R10R110000000000000001 R12ffffc90000433ba8 [] ffff888105986800 [287.684907R13]  0000000000000000 R14fffffffffffffe00 R15b FS: 6500 []100 287.692052100 [
    0000000000000000(0000) GS:ffff888277f80000(0000) knlGS:0000000000000000 [ 287.700149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 287.705897] CR2: 0000000000000070 CR3: 000000000320a000 CR4:
    0000000000350ee0 [ 287.713033] 呼叫追踪 [ 287.715498] raid1d+0x6c/0xbbb [raid1] [ 287.719256] ?
    __schedule+0x1ff/0x760 [ 287.722930] ? schedule+0x3b/0xb0 [ 287.726260] ? schedule_timeout+0x1ed/0x290 [287.730456] ? __switch_to+0x11f/0x400 [ 287.734219] md_thread+0xe9/0x140 [md_mod] [ 287.738328] ? md_thread+0xe9/0x140 [md_mod] [ 287.742601] ? wait_woken+0x80/0x80 [ 287.746097] ? md_register_thread+0xe0/0xe0 [md_mod] [ 287.751064] kthread+0x11a/0x140 [ 287.754300] ? kthread_park+0x90/0x90 [ 287.757974] ret_from_fork+0x1f/0x30 實際上當 raid1 陣列執行失敗時我們必須在 raid1_free() 之前執行 md_unregister_thread()。 (CVE-2022-50715)

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

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

  - iommufd不將相同的 hwpt 新增至 ioas->hwpt_list 兩次。hwpt 只會在建立期間新增至 hwpt_list 而不會再次新增。此區塊是因重新作業而遺漏的剩餘項目。在某些情況下新增兩次會損毀連結清單。它會影響 HWPT 特定的附件而這是測試套件無法涵蓋的內容直到我們可以使用非系統 iommu 驅動程式建立合法結構裝置 (即我們需要從 iommu 程式碼中移除匯流排) (CVE-2023-54043)

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

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

  - mediaanysee修正 anysee_master_xfer 中的 null-ptr-deref 在 anysee_master_xfer 中msg 由使用者控制。
    當 msg[i].buf 為 null 而 msg[i].len 為零時會通過之前對 msg[i].buf 的檢查。惡意資料最終到達 anysee_master_xfer。如果在沒有功能健全檢查的情況下存取 msg[i].buf[0]則會發生 null 指標解除參照。我們在 msg[i].len 上新增檢查以防止當機。類似的認可認可 0ed554fd769a (media
    dvb-usbaz6027修正 az6027_i2c_xfer() 中的 null-ptr-deref) [hverkuil在 + 周圍新增空格] (CVE-2023-54093)

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

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

  - wifiath9khif_usb修正 ath9k_hif_usb_dealloc_tx_urbs() 中 urbs 的記憶體洩漏。Syzkaller 報告 ath9k_hif_usb_dealloc_tx_urbs() 中由來已久的 urbs 洩漏。洩漏的原因是呼叫了 usb_get_urb()但未在 usb_kill_urb() 內部呼叫 usb_free_urb() (或 usb_put_urb())因為 urb->dev 或 urb->ep 欄位尚未初始化且 usb_kill_urb() 會立即傳回。此修補程式不會嘗試終止位於 hif_dev->tx.tx_buf 中的 urb因為 hif_dev->tx.tx_buf 不應包含處於擱置狀態的 urb (擱置 urb 儲存在 hif_dev->tx.tx_pending 中)。已取得 tx.tx_lock因此清單中不應有任何變更。由 Linux Verification Center (linuxtesting.org) 的 Syzkaller 發現。 (CVE-2022-50740)

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

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

  - scsiqla2xxx修正 NVMe LS 要求上的 DMA-API 呼叫追踪。在偵錯核心中發現下列訊息和呼叫追踪DMA-APIqla2xxx 0000:41:00.0裝置驅動程式無法檢查對應錯誤 [裝置 address=0x00000002a3ff38d8] [大小=1024 位元組] [對應為單一位元組] 警告CPU: 0 PID: 2930 at kernel/dma/debug.c:1017 check_unmap+0xf42/0x1990 呼叫追踪debug_dma_unmap_page+0xc9/0x100 qla_nvme_ls_unmap+0x141/0x210 [qla2xxx]從驅動程式中一併移除 DMA 對應因為 FC 層已執行此動作。這可以防止出現警告。 (CVE-2023-54108)

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

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

  - nvmet-tcp新增傳輸標籤 ttag 用作索引以取得 nvmet_tcp_handle_h2c_data_pdu() 中的 cmd 新增邊界檢查以避免超出邊界存取。 (CVE-2022-50717)

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

ID	名稱	嚴重性
279927	Linux Distros 未修補的弱點：CVE-2022-50712	medium
279926	Linux Distros 未修補的弱點：CVE-2023-54041	medium
279925	Linux Distros 未修補的弱點：CVE-2025-68920	high
279924	Linux Distros 未修補的弱點：CVE-2023-54066	medium
279923	Linux Distros 未修補的弱點：CVE-2022-50733	medium
279922	Linux Distros 未修補的弱點：CVE-2023-54072	medium
279921	Linux Distros 未修補的弱點：CVE-2023-54001	medium
279920	Linux Distros 未修補的弱點：CVE-2022-50723	medium
279919	Linux Distros 未修補的弱點：CVE-2022-50736	high
279918	Linux Distros 未修補的弱點：CVE-2022-50701	medium
279917	Linux Distros 未修補的弱點：CVE-2022-50706	medium
279916	Linux Distros 未修補的弱點：CVE-2023-54062	high
279915	Linux Distros 未修補的弱點：CVE-2023-54040	medium
279914	Linux Distros 未修補的弱點：CVE-2023-54033	medium
279913	Linux Distros 未修補的弱點：CVE-2023-54003	medium
279899	Linux Distros 未修補的弱點：CVE-2023-54099	high
279898	Linux Distros 未修補的弱點：CVE-2023-54119	medium
279897	Linux Distros 未修補的弱點：CVE-2022-50761	medium
279896	Linux Distros 未修補的弱點：CVE-2022-50783	medium
279895	Linux Distros 未修補的弱點：CVE-2022-50781	high
279894	Linux Distros 未修補的弱點：CVE-2023-54118	high
279893	Linux Distros 未修補的弱點：CVE-2022-50760	medium
279892	Linux Distros 未修補的弱點：CVE-2023-54156	medium
279891	Linux Distros 未修補的弱點：CVE-2023-54045	medium
279890	Linux Distros 未修補的弱點：CVE-2023-54069	high
279889	Linux Distros 未修補的弱點：CVE-2022-50726	high
279888	Linux Distros 未修補的弱點：CVE-2023-54052	medium
279887	Linux Distros 未修補的弱點：CVE-2022-50771	medium
279886	Linux Distros 未修補的弱點：CVE-2023-54128	medium
279885	Linux Distros 未修補的弱點：CVE-2023-54095	high
279884	Linux Distros 未修補的弱點：CVE-2023-54100	high
279883	Linux Distros 未修補的弱點：CVE-2023-54117	medium
279882	Linux Distros 未修補的弱點：CVE-2023-54089	high
279881	Linux Distros 未修補的弱點：CVE-2023-54131	medium
279880	Linux Distros 未修補的弱點：CVE-2022-50728	high
279879	Linux Distros 未修補的弱點：CVE-2023-54071	medium
279878	Linux Distros 未修補的弱點：CVE-2023-54110	high
279877	Linux Distros 未修補的弱點：CVE-2023-54070	medium
279876	Linux Distros 未修補的弱點：CVE-2022-50738	medium
279875	Linux Distros 未修補的弱點：CVE-2023-54084	high
279874	Linux Distros 未修補的弱點：CVE-2023-54123	medium
279873	Linux Distros 未修補的弱點：CVE-2022-50721	medium
279872	Linux Distros 未修補的弱點：CVE-2023-54096	high
279871	Linux Distros 未修補的弱點：CVE-2023-54148	high
279870	Linux Distros 未修補的弱點：CVE-2022-50715	medium
279869	Linux Distros 未修補的弱點：CVE-2023-54043	high
279868	Linux Distros 未修補的弱點：CVE-2023-54093	medium
279867	Linux Distros 未修補的弱點：CVE-2022-50740	medium
279866	Linux Distros 未修補的弱點：CVE-2023-54108	medium
279865	Linux Distros 未修補的弱點：CVE-2022-50717	high

偵測

Nessus 的 Misc. 系列

medium

medium

high

medium

medium

medium

medium

medium

high

medium

medium

high

medium

medium

medium

high

medium

medium

medium

high

high

medium

medium

medium

high

high

medium

medium

medium

high

high

medium

high

medium

high

medium

high

medium

medium

high

medium

medium

high

high

medium

high

medium

medium

medium

high