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 的判定取決於廠商所報告的套件是否存在。

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

  - smb用戶端修正遺漏的 ses refcounting 使用新的 cifs_smb_ses_inc_refcount() 協助程式取得 @ses 和 @ses->dfs_root_ses (若已設定) 的使用中參照。這將防止 @ses->dfs_root_ses 放在下一次對 cifs_put_smb_ses() 的呼叫中因而可能造成釋放後使用錯誤。 (CVE-2023-54076)

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

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

  - mmcmxcmmc修正 mmc_add_host() 的傳回值檢查 mmc_add_host() 可能傳回錯誤若忽略其傳回值則會洩漏在 mmc_alloc_host() 中配置的記憶體且會因為刪除非新增而導致核心損毀device 中的移除路徑。請檢查傳回值並前往會呼叫 mmc_free_host() 的 goto 錯誤路徑藉此修正此問題。 (CVE-2022-50769)

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

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

  -調節器核心修正 Regulator_register() 中的資源洩漏執行錯誤插入測試時我收到了一些資源洩漏報告OF: 錯誤記憶體洩漏預期是 1 而非 100of_node_get()/of_node_put() 不平衡 - 損毀 cset 項目附加重疊節點 /i2c/pmic@64/regulators/buck1 未參照的物件 0xffff88810deea000 (大小 512)comm 490-i2c-rt5190a、pid 253、jiffies 4294859840 (5061.046s) 十六進位轉儲存 (前 32 位元組) 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N........ ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff ..... ........ 反向追踪
    [<00000000d78541e2>] kmalloc_trace+0x21/0x110 [<00000000b343d153>] device_private_init+0x32/0xd0 [<00000000be1f0c70>] device_add+0xb2d/0x1030 [<00000000e3e6344d>]ulator_register+0xaf2/0x12a0 [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0 [<000000008b898197>] rt5190a_probe +0x52a/0x861 [rt5190a_regulator] 未參照的物件 0xffff88810b617b80 (大小 32)comm 490-i2c-rt5190a, pid 253, jiffies 4294859904 (age 5060.983s) hex 轉儲存 (前 32 個位元組): 72 65 747 67 75 261 72 72 65 74 7f 7c 261 十六進位轉儲存 (前 32 個位元組) 32 38 36 38 2d 53 Regulator.2868-S 55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00 UPPLY...)...+... backtrace
    [<000000009da9280d>] __kmalloc_node_track_caller+0x44/0x1b0 [<0000000025c6a4e5>] kstrdup+0x3a/0x70 [<00000000790efb69>] create_regulator+0xc0/0x4e0 [<0000000005ed203a>] graphite_regulator_resolve_supply+0x2d4/0x440 [<0000000045796214>] graphite_regulator_register+0x10b3/0x12a0 [<00000000e2f5e754>] devm_regulator_register +0x57/0xb0 [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator] 在呼叫 Regulator_resolve_supply() 之後set_supply() 設定了「rdev->supply」在此設定之後錯誤路徑中的資源必須釋放因此請呼叫 Regulator_put() 以避免洩漏。 (CVE-2022-50724)

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

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

  - scsilpfc防止 lpfc_debugfs_lockstat_write() 緩衝區溢位。靜態程式碼分析工具標記出針對 debugfs 項目使用 copy_from_user() 時可能發生緩衝區溢位。目前copy_from_user() 複製的位元組數量可能比 mybuf char 陣列可容納的數量還多。在 sizeof(mybuf) - 1 和 nbytes 之間新增 min() 限制檢查從使用者空間緩衝區傳送以防止緩衝區溢位。 (CVE-2023-54102)

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

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

  - ixgbe修正 XDP_TX with > 64 CPU Commit 期間的不穩定 4fe815850bdc (ixgbe讓 xdpdrv 與超過 64 個 cpu 搭配使用) 新增支援以允許 XDP 程式鎖定 XDP TX 環並為其編制索引以便在具有超過 64 個 CPU 的系統上執行使用 cpu %64 (IXGBE_MAX_XDP_QS)。在具有超過 64 個核心的系統上嘗試此修補程式時核心發生錯誤並在 ixgbe.h 的 ixgbe_determine_xdp_ring 中傳回 array-index-out-of-bounds 這表示 ixgbe_determine_xdp_q_idx 僅傳回 cpu 而非 cpu % IXGBE_MAX_XDP_QS。範例說明
    ================================================== ======================== UBSAN array-index-out-of-bounds 在 /var/lib/dkms/ixgbe/ 中5.18.6+focal-1/build/src/ixgbe .h:1147:26 索引 65 超出類型 'ixgbe_ring *[64]' 的範圍 ============================= ============================================= 錯誤核心 NULL 指標解除參照、位址0000000000000058 #PF核心模式中的監督讀取權限 #PF
    error_code(0x0000) - 不存在頁面 PGD 0 P4D 0 Oops0000 [#1] SMP NOPTI CPU65 PID408 Comm
    ksoftirqd/65 受污染G IOE 5.15.0-48-generic #54~20.04.1-Ubuntu 硬體名稱 Dell Inc. PowerEdge R640/0W23H8, BIOS 2.5.4 2020 年 1 月 13 日 RIP0010:ixgbe_xmit_xdp_ring+0x1b/ 0x1c0 [ixgbe] 代碼3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 053 48 83 8 <44> [ec] 0f b7 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0 RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282 RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000 RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000 RBP: ffffbc3fcd88fce0 R08ffff92b9dfc20580 R09
     R100000000000000001  : 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000 R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c FS: 0000000000000000(0000) GS:ffff92b9dfc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 CR20000000000000058 CR3
    000000011dd6a002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ixgbe_poll+0x103e/0x1280 [ixgbe] ? sched_clock_cpu+0x12/0xe0 __napi_poll+0x30/0x160 net_rx_action+0x11c/0x270 __do_softirq+0xda/0x2ee run_ksoftirqd+0x2f/0x50 smpboot_thread_fn+0xb7/0x150 sort_range+0x30/0x30 kthread+0x127/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x30 </TASK> 我認為實際情況如下在具有 64 個以上 CPU 的系統上載入第一個 XDP 程式時ixgbe_xdp_setup 中的 ixgbe_xdp_locking_key 遞增。不過在此之後ixgbe_setup_tc 會立即重新設定環。 ixgbe_setup_tc 會呼叫 ixgbe_clear_interrupt_scheme而後者會呼叫 ixgbe_free_q_vectors而後者又會在迴圈中呼叫 ixgbe_free_q_vector。若 ixgbe_free_q_vector 每次呼叫非零則 ixgbe_free_q_vector 將其遞減一次。取消註解 ixgbe_free_q_vector 中的遞減可使我的系統避免錯誤。我懷疑要使原始修補程式正常運作我需要載入一個 XDP 程式然後將其取代因為 ixgbe_setup_tc 只會在 XDP 和非 XDP 環組態之間轉換時被呼叫一次且 ixgbe_xdp_locking_key 會增加至 0 以上呼叫 ixgbe_xdp_setup 的時間。此外可透過 ethtool --set-channels呼叫 ixgbe_setup_tc因此這會變成在具有超過 64 個 CPU 的系統上將 ixgbe_xdp_locking_key 遞減至 0 的另一個路徑。由於 ixgbe_xdp_locking_key 僅保護 XDP_TX 路徑且與存在的 CPU 數量相關因此沒有理由在卸載 XDP 程式時予以停用。為避免混淆我已將啟用 ixgbe_xdp_locking_key 移至探查路徑一部分的 ixgbe_sw_init 中。 (CVE-2023-54090)

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

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

  - ext4修正 __es_tree_search 中由錯誤配額 inode 造成的 bug_on。遇到下列問題
    ================================================== ================ fs/ext4/extents_status.c:202! 的核心錯誤無效 opcode0000 [#1] PREEMPT SMP CPU1 PID810 Commmount 未受污染的 6.1.0-rc1-next-g9631525255e3 #352 RIP0010:__es_tree_search.isra.0+0xb8/0xe0 RSP
    0018:ffffc90001227900 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000077512a0f RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000002a10 RDI: ffff8881004cd0c8 RBP: ffff888177512ac8 R08:
     R0947ffffffffffffff  : 0000000000000001 R10: 0000000000000001 R11: 00000000000679af R12: 0000000000002a10 R13: ffff888177512d88 R14: 0000000077512a10 R15: 0000000000000000 FS:
    00007f4bd76dbc40(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0
    0000000080050033 CR2: 00005653bf993cf8 CR3: 000000017bfdf000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: <TASK> ext4_es_cache_extent+0xe2/0x210 ext4_cache_extents+0xd2/0x110 ext4_find_extent+0x5d5/0x8c0 ext4_ext_map_blocks+0x9c/0x1d30 ext4_map_blocks+0x431/0xa50 ext4_getblk+0x82/0x340 ext4_bread+0x14/0x110 ext4_quota_read+0xf0/0x180 v2_read_header+0x24/ 0x90 v2_check_quota_file+0x2f/0xa0 dquot_load_quota_sb+0x26c/0x760 dquot_load_quota_inode+0xa5/0x190 ext4_enable_quotas+0x14c/0x300 __ext4_fill_super+0x31cc/0x32c0 ext4_fill_super+0x115/0x2d0 get_tree_bdev+0x1d2/0x360 ext4_get_tree+0x19/0x30 vfs_get_tree+0x26/0xe0 path_mount+0x81d/ 0xfc0 do_mount+0x8d/0xc0 __x64_sys_mount+0xc0/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> =========================== ======================================= 以上問題可能發生如下
    ------------------------------------- ext4_fill_super ext4_orphan_cleanup ext4_enable_quotas ext4_quota_enable ext4_iget --> 取得錯誤 inode <5> ext4_ext_check_inode --> Wrong imode makes it escape inspection make_bad_inode(inode) --> EXT4_BOOT_LOADER_INO set imode dquot_load_quota_inode vfs_setup_quota_inode --> check pass dquot_load_quota_sb v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent __es_tree_search.isra.0 ext4_es_end --> Wrong extents trigger BUG_ON 在上述問題中s_usr_quota_inum 設為 5但 inode<5> 包含錯誤的 imode 和無序的範圍。因為 5 是 EXT4_BOOT_LOADER_INO因此可以繞過 ext4_iget 函式中的 ext4_ext_check_inode 檢查最後未檢查的範圍會觸發
    __es_tree_search 函式。若要解決此問題請檢查 inode 是否為 vfs_setup_quota_inode() 中的 bad_inode。 (CVE-2022-50782)

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

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

  - canisotp檢查 isotp_bind() 中的 CAN 位址系列新增遺漏的檢查以封鎖 non-AF_CAN 系結。Syzbot 建立了一些程式碼其符合正確的 sockaddr 結構大小但在位址系列欄位中使用 AF_XDP (0x2C) 而非 AF_CAN (0x1D)bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2 }、0x10) ^^^^ 這不會造成任何功能影響但使用者空間會收到錯誤位址系列欄位內容的通知。 (CVE-2023-54105)

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

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

  - net修正 ops_init() 失敗時 nfqnl_nf_hook_drop() 中的 UAF 問題當叫用 ops_init() 介面初始化 net 時若 ops->init() 失敗則會釋出資料。不過net->gen 中的 ptr 指標無效。在此情況下叫用 nfqnl_nf_hook_drop() 以釋放網路時會發生無效的位址存取。處理程序如下setup_net() ops_init() data = kzalloc(...) ---> alloc data net_assign_generic() ---> 指派日期給 net->gen 中的 ptr ... ops->init( ) ---> 失敗 ... kfree(data);
    ---> net->gen 中的 ptr 無效 ... ops_exit_list() ... nfqnl_nf_hook_drop() *q = nfnl_queue_pernet(net)
    ---> q 無效 以下是呼叫追踪資訊錯誤 KASAN工作 ip/15855 呼叫追踪 <TASK> dump_stack_lvl+0x8e在 addr ffff88810396b240 讀取 nfqnl_nf_hook_drop+0x264/0x280 中大小為 8 的錯誤/0xd1 print_report+0x155/0x454 kasan_report+0xba/0x1f0 nfqnl_nf_hook_drop+0x264/0x280 nf_queue_nf_hook_drop+0x8b/0x1b0 __nf_unregister_net_hook+0x1ae/0x5a0 nf_unregister_net_hooks+0xde/0x130 ops_exit_list+0xb0/0x170 setup_net+0x7ac/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382 /0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> 由工作 15855 配置
    kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0xa1/0xb0 __kmalloc+0x49/0xb0 ops_init+0xe7/0x410 setup_net+0x5aa/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 已由工作 15855 釋放
    kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40
    ____kasan_slab_free+0x155/0x1b0 slab_free_freelist_hook+0x11b/0x220 __kmem_cache_free+0xa4/0x360 ops_init+0xb9/0x410 setup_net+0x5aa/0xbd0 copy_net_ns+0x2e6/0x6b0 create_new_namespaces+0x382/0xa50 unshare_nsproxy_namespaces+0xa6/0x1c0 ksys_unshare+0x3a4/0x7e0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-50780)

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

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

  - KVMs390pv修正取代 ASCE 的索引值與來賓 ASCE 對應的結構頁面索引欄位應為 0。在 s390_replace_asce() 中取代 ASCE 時新 ASCE 的索引也應設定為 0 。錯誤索引可能會導致在通知 pte 無效判定時傳遞錯誤的位址如果前置詞取消對應並呼叫通知程式時會使用錯誤的位址最終導致有效性攔截 (VM 當機)。 (CVE-2023-54092)

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

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

  - maple_tree修正 mas_wr_end_piv() 中潛在的超出邊界存取。在使用寫入位移結束邊界作為樞紐陣列的位移之前先加以檢查。這可在寫入延伸至節點中的最後一個插槽時避免樞紐陣列上可能發生的超出邊界存取在此情況下應將節點最大值做為結束樞紐。 akpm這不會影響任何目前的呼叫端但是如果 mapletree 的新使用者反向移植到更早的核心中可能會遇到此問題讓我們在穩定的核心中修正此問題以防發生此情況。 (CVE-2023-54135)

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

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

  - cryptoqat - 修正 DMA 傳輸方向若選取了 CONFIG_DMA_API_DEBUG在 QAT crypto 演算法上執行 crypto 自我測試時add_dma_entry() 函式會報告類似下列的警告指出不支援重疊對應。輸入和輸出分散清單指向相同緩衝區 (即指向相同記憶體區塊的兩個不同分散清單) 的測試中會發生這個情況。實作該對應的邏輯針對輸入和輸出分散清單使用 DMA_BIDIRECTIONAL 旗標這會導致重疊的寫入對應。這些不受 DMA 層支援。透過在對應緩衝區時指定正確的 DMA 傳輸方向來修正。針對輸入分散清單符合輸出分散清單的就地作業緩衝區會與 DMA_BIDIRECTIONAL 對應一次否則輸入緩衝區會使用旗標 DMA_TO_DEVICE 對應而輸出緩衝區則與 DMA_FROM_DEVICE 對應。在 dma-coherent 裝置 (如 QAT) 中讀取對應與寫入對應重疊是一種有效的情況。釋放和取消對應緩衝區的函式 qat_alg_free_bufl() 已根據對應函式的變更而變更。DMA-API4xxx 0000:06:00.0cacheline 追踪 EEXIST不支援重疊對應警告CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270 ... 呼叫追踪dma_map_page_attrs+0x82/0x2d0 preempt_count_add+0x6a/0xa0 qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat] qat_alg_aead_dec+0x71/0x250 [intel_qat] crypto_aead_decrypt+0x3d/0x70 test_aead_vec_cfg+0x649/0x810 ? number+0x310/0x3a0 ? vsnprintf+0x2a3/0x550 ? scnprintf+0x42/0x70 ? valid_sg_divisions.constprop.0+0x86/0xa0 test_aead_vec+0xdf/0x120 test_aead_vec+0xdf/0x120 alg_test_aead+0x185/0x400 alg_test+0x3d8/0x500 ? crypto_acomp_scomp_free_ctx+0x30/0x30 ? __schedule+0x32a/0x12a0 ? ttwu_queue_wakelist+0xbf/0x110 ?
    _raw_spin_unlock_irqrestore+0x23/0x40 ? try_to_wake_up+0x83/0x570 ? _raw_spin_unlock_irqrestore+0x23/0x40 ? __set_cpus_allowed_ptr_locked+0xea/0x1b0 ? crypto_acomp_scomp_free_ctx+0x30/0x30 cryptomgr_test+0x27/0x50 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 (CVE-2022-50774)

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

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

  - btrfs修正平衡和取消/暫停之間的爭用。Syzbot 報告如下所示的錯誤宣告失敗fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 --------- ---[在此處切入]------------ fs/btrfs/messages.c:259! 的核心錯誤RIP0010btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 呼叫追踪 <TASK> btrfs_exclop_balance fs/btrfs/ioctl.c:465 [內嵌] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [內嵌] btrfs_ioctl +0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [內嵌] __do_sys_ioctl fs/ioctl.c:870 [內嵌] __se_sys_ioctl fs/ioctl.c:856 [內嵌] __x64_sys_ioctl+0x197/ 0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [內嵌] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 播放機正在執行平衡以及平行執行的取消或暫停。平衡完成的方式有點不穩定如果我們暫停則需要儲存 fs_info 中的 balance_ctl否則清除它並進行清理。不過我們會依據特定錯誤或具有取消要求或無暫停要求的傳回值。如果平衡作業完成並傳回 0但我們有暫停或取消要求我們將不會執行適當的清理因此下次我們嘗試開始平衡時我們會觸發此 ASSERT。錯誤處理在這裡是錯誤的我們一律要清除除非我們得到 -ECANCELLED而且我們在獨占 op 中設定適當的暫停旗標。使用此修補程式後播放器可連續執行一個小時而不會發生錯誤之前的情況下它會在幾分鐘內發生錯誤。 (CVE-2023-54023)

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

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

  - udf避免 udf_rename() 中發生雙重 brelse() syzbot 報告了一個類似以下的警告 [1]: VFSbrelse: Trying free free buffer 警告CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67 /0xa0 ... 呼叫追踪：
    <TASK> invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ? smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 lock_release+0x587/0x810
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80 blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760 deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0 task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ? reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ? rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd 此問題的原因是 udf_find_entry() 在傳回 NULL 時在 ofibh.sbh 和 ofibh.ebh 上呼叫了 brelse()。不過udf_rename() 也會呼叫 brelse()。因此buffer_head 上的 b_count 會變得不平衡。此修補程式修正了此問題在 udf_find_entry() 傳回 NULL 時不由 udf_rename() 呼叫 brelse()。 (CVE-2022-50755)

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

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

  - sched/psi針對 PSI 觸發程序輪詢使用 kernfs 輪詢函式。從輪詢處理程序中移除 cgroup 時破壞 cgroup_file_release 中的 psi 觸發程序會造成 UAF 問題。此情況之所以發生是因為 cgroup 移除造成在實際檔案仍然存在時呼叫 cgroup_file_release。若此時損毀觸發程序也會損毀其 waitqueue 標頭且如果該檔案上仍有輪詢處理程序正在存取 waitqueue則會步進釋放的指標do_select vfs_poll do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy wake_up_pollfree(&t->event_wait) // vfs_poll 已解除封鎖 synchronize_rcu kfree(t) poll_freewait -> UAF 存取觸發程序的 waitqueue 標頭 修補程式 [1] 已修正使用 wake_up_pollfree() 的 epoll() 案例的這個問題但是同步 poll() 案例中存在相同的問題。此問題的根本原因是 psi 觸發程序的等候佇列與觸發程序相關檔案的生命週期不同。修正此方法為在 cgroup 特定 psi 觸發程序上輪詢時使用 kernfs_generic_poll 函式。它在內部使用 kernfs_open_node->poll waitqueue 標頭其生命週期與檔案的生命週期相關。這也會導致 [1] 中的修正過時因此請將其還原。 [1] 提交 c2dbe32d5db5 (sched/psi
    修正 ep_remove_wait_queue() 中的釋放後使用 (CVE-2023-54019)

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

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

  - octeontx2-af新增 lmac 類型的驗證實體連結變更時韌體會向核心報告變更情況以及速度、lmac_type_id 等詳細資料。核心根據從韌體接收的 lmac_type_id 衍生 lmac_type。在少數情況下韌體會傳回無效的 lmac_type_id其會導致下列核心錯誤。此修補程式新增了 lmac_type_id 欄位遺漏的驗證。
    內部錯誤Oops96000005 [#1] PREEMPT SMP [ 35.321595] 連結於的模組[ 35.328982] CPU0 PID
    31 Commkworker/0:1 未受污染的 5.4.210-g2e3169d8e1bc-dirty #17 [ 35.337014] 硬體名稱Marvell CN103XX board (DT) [ 35.344297] 工作佇列事件 work_for_cpu_fn [ 35.352730] pstate 40400089 (nZcv daIf + PAN -UAO) [ 35.360267] pc strncpy+0x10/0x30 [ 35.366595] lr cgx_link_change_handler+0x90/0x180 (CVE-2023-54129)

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

ID	名稱	嚴重性
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	medium
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
279864	Linux Distros 未修補的弱點：CVE-2023-54076	high
279863	Linux Distros 未修補的弱點：CVE-2022-50769	medium
279862	Linux Distros 未修補的弱點：CVE-2022-50724	medium
279861	Linux Distros 未修補的弱點：CVE-2023-54102	high
279860	Linux Distros 未修補的弱點：CVE-2023-54090	medium
279859	Linux Distros 未修補的弱點：CVE-2022-50782	high
279858	Linux Distros 未修補的弱點：CVE-2023-54105	high
279856	Linux Distros 未修補的弱點：CVE-2022-50780	high
279855	Linux Distros 未修補的弱點：CVE-2023-54092	medium
279854	Linux Distros 未修補的弱點：CVE-2023-54135	high
279853	Linux Distros 未修補的弱點：CVE-2022-50774	high
279852	Linux Distros 未修補的弱點：CVE-2023-54023	medium
279851	Linux Distros 未修補的弱點：CVE-2022-50755	medium
279850	Linux Distros 未修補的弱點：CVE-2023-54019	medium
279849	Linux Distros 未修補的弱點：CVE-2023-54129	medium

偵測

Nessus 的 Misc. 系列

high

medium

medium

medium

high

high

medium

medium

medium

high

high

medium

medium

medium

high

high

medium

high

medium

medium

medium

high

medium

medium

high

medium

medium

high

high

medium

high

medium

medium

medium

high

high

medium

medium

high

medium

high

high

high

medium

high

high

medium

medium

medium

medium