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

  - 在 Linux 系統上整合 Active Directory 與系統安全性服務程序 (SSSD) 的過程中發現一個瑕疵。在預設組態中啟用 Kerberos 本機驗證外掛程式 (sssd_krb5_localauth_plugin)但可遞補至 an2ln 外掛程式。此遞補允許具有修改特定 AD 屬性 (例如 userPrincipalName 或 samAccountName) 權限的攻擊者模擬有權限的使用者這可能導致在加入網域的 Linux 主機上進行未經授權的存取或權限提升。 (CVE-2025-11561)

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

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

  - iommu/amd/pgtbl修正增加頁面表格層級時可能發生的爭用。AMD IOMMU 主機頁面表格實作支援動態頁面表格層級 (最多 6 個層級)，從根據 IOVA 位址擴充的 3 層級組態開始。核心會維護一個 root 指標和目前的頁面表格層級以便在 alloc_pte()/fetch_pte() 作業中啟用適當的頁面表格查詢。IOMMU IOVA 配置器最初以 32 位元位址啟動一旦用盡便切換至 64 位元位址 (位址上限視 IOMMU 和裝置 DMA 功能而定)。為了支援更大的 IOVAAMD IOMMU 驅動程式增加了頁面表格層級。但在取消對應路徑中 (iommu_v1_unmap_pages())fetch_pte() 會在無鎖定的情況下讀取 pgtable->[root/mode]。因此在極端情況下increase_address_space() 更新 pgtable->[root/mode] 時fetch_pte() 可能讀取錯誤的頁面表格層級 (pgtable->mode)。它會比較該值與頁面表格中編碼的層級並傳回 NULL。這將導致 iommu_unmap ops 失敗且上層可能會重試/記錄 WARN_ON。CPU 0 CPU 1 ------ ------ 對應頁面 unmap page alloc_pte() ->increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (新 root 值) READ pgtable- >[mode/root] 讀取新的 root舊模式更新模式 (pgtable->mode += 1) 由於頁面表格層級更新不常使用且已與執行緒同步鎖定同步因此請實作 seqcount 以在讀取路徑上啟用無鎖定讀取作業。 (CVE-2025-39961)

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

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

  - wifimac80211增加 S1G 的 scan_ies_len 目前 scan_ies_len 並未將 S1G 功能元素納入考量這會導致 ieee80211_prep_hw_scan() 中出現緩衝區長度驗證失敗以及 __ieee80211_start_scan() 中後續出現 WARN。這可防止 hw 掃描正常運作。確保我們容納 S1G 功能長度以修正 。 (CVE-2025-39957)

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

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

  - iommu/s390: 當裝置遭到意外移除時使附加成功當使用意外熱插拔移除 PCI 裝置時作為卸除的一部分可能仍會嘗試將裝置附加至預設網域 (__iommu_release_dma_ownership())或因為移除會在探查期間發生 (__iommu_probe_device())。在這兩種情況下zpci_register_ioat() 都會失敗並出現 cc 值指示裝置處置程式無效。這是因為就 Hypervisor 而言裝置不再屬於執行個體。目前這會導致錯誤傳回且 s390_iommu_attach_device() 失敗。
    這會觸發 __iommu_group_set_domain_nofail() 中的 WARN_ON()因為附加至預設網域絕不會失敗。在以 hypervisor 隔離裝置的情況下不可能有傳入或傳出記憶體的 DMA因此 IOMMU 轉譯沒有任何效果。以註冊成功的方式繼續執行，並讓熱插拔事件處理程序清理裝置。這與自認可 59bbf596791b (iommu/s390即使裝置處於錯誤狀態也使附加成功) 以來錯誤狀態中裝置的處理方式類似但若要移除網域將不會稍後再註冊。此方法先前也已在該連結中討論過。
    在檢查錯誤是否需要傳播或忽略的協助程式中同時處理錯誤狀態和移除這兩種情況。透過使用先前存在但從未使用過的 PCI 載入/儲存條件程式碼定義來避免魔術數字條件程式碼並將其重新命名以反映其適用於所有 PCI 指令。
    (CVE-2025-39958)

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

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

  - io_uring修正 io_link_skb 中不正確的 io_kiocb 參照。在 io_link_skb 函式中存在一個使用「nd」而非「prev_nd」錯誤指派 prev_notif 的錯誤。這會造成內容驗證檢查將目前的通知與其本身進行比較而非與之前的通知進行比較。取得 prev_notif 時透過使用正確的 prev_nd 參數來修正。 (CVE-2025-39963)

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

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

  - igc不會使 LED 設定錯誤的 igc_probe() 失敗當 igc_led_setup() 失敗時由於未呼叫 unregister_netdev()igc_probe() 也會失敗並在 free_netdev() 中觸發核心錯誤。 [1] 可使用錯誤插入架構測試此行為尤其是使用 failslab 功能。 [2] 由於 LED 支援並非強制要求請將 LED 設定失敗視為非嚴重並繼續探查並顯示警告訊息進而避免核心錯誤。 [1] net/core/dev.c:12047! 的核心錯誤Oops無效 opcode0000 [#1] SMP NOPTI CPU0 UID0 PID937 Commrepro-igc-led-e 未受污染的 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(vulnerable ) 硬體名稱QEMU Standard PC (Q35 + ICH9, 2009)BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP 0010:free_netdev+0x278/0x2b0 [...] 呼叫追踪 <TASK> igc_probe+0x370/0x910 local_pci_probe+0x3a/0x80 pci_device_probe+0xd1/0x200 [...] [2] #!/bin/bash -ex FAILSLAB_PATH=/sys/kernel/debug/failslab/ DEVICE=0000:00 05.0 START_ADDR=$(grep igc_led_setup /proc/kallsyms \ | awk '{printf(0x%s, $1)}') END_ADDR=$(printf 0x%x $((START_ADDR + 0x100))) echo $START_ADDR > $FAILSLAB_PATH/require-start echo $END_ADDR > $FAILSLAB_PATH/require-end echo 1 > $FAILSLAB_PATH/times echo 100 > $FAILSLAB_PATH/probability echo N > $FAILSLAB_PATH/ignore-gfp-wait echo $DEVICE > /sys/bus/pci/drivers/igc/bind (CVE-2025-39956)

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

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

  - tcp清除 tcp_disconnect() 中的 tcp_sk(sk)->fastopen_rsk。 syzbot 在以下報告指出通訊端的 tcp_sk(sk)->fastopen_rsk 處於 TCP_ESTABLISHED 狀態。 [0] 在 TFO 通訊端完成之前syzbot 重複使用伺服器端 TCP Fast Open 通訊端作為新用戶端 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3.
    connect() 到另一個目的地 從 accept() 開始sk->sk_state 為 TCP_SYN_RECV且 tcp_disconnect() 將其變更為 TCP_CLOSE並使 connect() 成為可能進而重新啟動計時器。由於 tcp_disconnect() 忘記清除 tcp_sk(sk)->fastopen_rsk因此重新傳輸計時器會觸發警告且不會重新傳輸預定的封包。讓我們呼叫 tcp_disconnect() 中的 reqsk_fastopen_remove()。 [0]: 警告CPU 2 PID在 net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (辨別器 7)) 中的模組連結CPU2 UID0 PID 0 Commswapper/2 未受污染的 6.17.0-rc5-g201825fb4278 #62 PREEMPT(自發) 硬體名稱: QEMU Standard PC (i440FX + PIIX, 1996)、BIOS 1.16.3-debian-1.16.3-2 04/01 /2014 RIP
    0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (辨別器 7)) 程式碼 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 123 3 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS:900102 03
    0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10:
     R1100000000000000c2  : ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 呼叫追踪 <IRQ> tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747)
    __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135 ) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (辨別器 1)) tmigr_handle_remote (kernel/time/timer_migration。 c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c: 614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/ apic.c:1050 (判別器 35)) </IRQ> (CVE-2025-39955)

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

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

  - tracing/hist修正「action_data.var_ref_idx」的超出邊界寫入。使用多個參數產生綜合事件然後為其建立追踪動作 [1] 時發生核心錯誤 [2]。這是因為在 trace_action_create() 中'data->n_params' 的上限是 SYNTH_FIELDS_MAX (目前值為 64)而陣列 'data->var_ref_idx' 會將每個綜合事件參數的索引保留在陣列 'hist_data->var_refs' 中但是「data->var_ref_idx」的長度為 TRACING_MAP_VARS_MAX (目前值為 16)因此當「data->n_params」超過 16 時會發生超出邊界寫入。在此情況下「data->match_data.event」會遭到覆寫並最終造成發生錯誤。若要解決此問題請將 'data->var_ref_idx' 的長度調整為 SYNTH_FIELDS_MAX並新增功能健全檢查以避免超出邊界寫入。 [1] # cd /sys/kernel/tracing/ # echo my_synth_event int v1 int v2 int v3 int v4 int v5 int v6\ int v7; int v8 int v9 int v10 int v11
    int v12 int v13 int v14\ int v15; int v16 int v17 int v18 int v19 int v20 int v21 int v22\ int v23; int v24 int v25 int v26 int v27 int v28 int v29 int v30\ int v31; int v32 int v33 int v34
    int v35 int v36 int v37 int v38\ int v39; int v40 int v41 int v42 int v43 int v44 int v45 int v46\ int v47 int v48 int v49 int v50 int v51 int v52 int v53 int v54\ int v55; int v56 int v57
    int v58 int v59 int v60 int v61 int v62;\ int v63 >> graphite_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm==bash' >> \events/sched/sched_waking/trigger # echo Hist:keys=next_pid:onmatch(sched .sched_waking).my_synth_event(\pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\pid,pid,pid, pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid ,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid) >> event/sched/sched_switch/trigger [2] 錯誤無法處理下列位址的頁面錯誤ffff91c900000000 PGD 61001067 P4D 61001067 PUD 0 Oops0000 [#1] PREEMPT SMP NOPTI CPU
    2 PID322 Comm: bash 污染的 GW 6.1.0-rc8+ #229 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01 /2014 RIP0010:strcmp+0xc/0x30 程式碼75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3 RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff91c943d33a90 RDIffff91c900000000 RBPffff91c900000000 R0800000018d604b529 R09
     R100000000000000000  : ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580 R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538 FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 CR2ffff91c900000000 CR3
    0000000006316000 CR400000000000006e0 呼叫追踪 <TASK> __find_event_file+0x55/0x90 action_create+0x76c/0x1060 event_hist_trigger_parse+0x146d/0x2060 event_trigger_write+0x31/0xd0 trigger_process_regex+0xbb/0x110 event_trigger_write+0x6b/0xd0 vfs_write+0xc8/0x3e0 alloc_fd+0xc0/0x160 ? preempt_count_add+0x4d/0xa0 preempt_count_add+0x70/0xa0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f1d1d0cf077 Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX在
    0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077 RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001 RBP: 00005639265aa7e0 R08: 000000000000000a R09:
    0000000000000142 R ---truncated--- (CVE-2022-50553)

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

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

  - netfilterconntrack修正錯誤的 ct->timeout 值 (struct nf_conn)->timeout 是確認 conntrack 之前的間隔。確認後會變成一個時間戳記。據發現未確認的 conntrack 逾時 - 藉由呼叫 ctnetlink_change_timeout() 來設定。因此「nfct_time_stamp」被錯誤地新增至「ct->timeout」兩次。- 透過呼叫 ctnetlink_dump_timeout() 取得。因此錯誤減去 `nfct_time_stamp`。呼叫追踪 <TASK> dump_stack_lvl ctnetlink_dump_timeout
    __ctnetlink_glue_build ctnetlink_glue_build __nfqnl_enqueue_packet nf_queue nf_hook_slow ip_mc_output
    __pfx_ip_finish_output ip_send_skb __pfx_dst_output udp_send_skb udp_sendmsg __pfx_ip_generic_getfrag sock_sendmsg 在 中區分 2 種案例- 設定 __nf_ct_set_timeout() 中的 `ct->timeout`。- 在 ctnetlink_dump_timeout() 中取得 `ct->timeout`。Pablo 附加更新 ctnetlink以便在 IPS_CONFIRMED 旗標設定為開啟之後設定逾時否則透過 ctnetlink 建立的 conntrack 會中斷。請注意自從引入 nfnetlink_queue conntrack 支援後就會發生此修補程式中所述的問題請選取足夠舊的 Fixes: 標籤讓穩定的核心 擷取此修正。 (CVE-2023-53635)

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

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

  - perf/smmuv3修正 arm_smmu_pmu_init() 中的熱插拔回呼洩漏。 platform_driver_register() 失敗時arm_smmu_pmu_init() 不會移除 cpuhp_setup_state_multi() 新增的回呼。移除失敗路徑中 cpuhp_remove_multi_state() 的回呼。與認可 26242b330093 中的 arm_ccn_init() 處理類似 (匯流排 arm-ccn防止熱插拔回呼洩漏) (CVE-2022-50510)

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

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

  - scsihisi_sas遊走 sas_dev.list 的成員時抓取 sas_dev 鎖定。釋放函式 slot_complete_v3_hw() 中的插槽時可能會在其他地方遊走 sas_dev.list而且它可能會觸發 NULL 指標例外狀況如下所示==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task() ==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free( ) ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe() [ 7165.434918] sas輸入 sas_scsi_recover_host busy32 失敗32 [7165.434926] sas嘗試尋找工作 0x00000000769b5ba5 [ 7165.434927] sas sas_scsi_find_task: aborting task 0x00000000769b5ba5 [ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted [ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored [7165.434965] hisi_sas_v3_hw 0000: b4:02.0插槽完成已忽略 task(00000000e2a1cf01) [ 7165.434968] 無法處理核心 NULL 指標r 在虛擬位址 0000000000000000 處解除參照 [ 7165.434972] Hisi_sas_v3_hw 0000:b4:02.0插槽完成已忽略 task(0000000022d52d93) 7165.434975] Hisi_sas_v3_hw 0000:b4:02.0插槽完成 task(0000000066 Mea7516c) 7165.434976已忽略info[ 7165.434982] ESR = 0x96000004 [ 7165.434991] 例外狀況類別 = DABT (目前 EL)、IL = 32 位元 [ 7165.434992] SET = 0、FnV = 0 [ 7165.434993] EA = 0、S1PTW = 0 [ 7165.434994] 資料中止資訊[ 7165.434994] ISV = 0, ISS = 0x00000004 [ 7165.434995] CM = 0, WnR = 0 [ 7165.434997] 使用者 pgtable4k 頁面, 48 位元 VA, pgdp = 00000000f29543f2 [ 7165.434998] [0000000000000000] pgd=0000000000000000 [ 7165.435003] 內部錯誤
    Oops96000004 [#1] SMP [ 7165.439863] 處理程序 scsi_eh_6 (pid4109、堆疊限制 = 0x00000000c43818d5) [7165.468862] pstate00c00009 (nzcv daif +PAN +UAO) [ 7165.473637] pc dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [ 7165.479443] lrdereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw] [ 7165.485247] sp
    ffff00001d623bc0 [ 7165.488546] x29 ffff00001d623bc0 x28ffffa027d03b9508 [ 7165.493835] x27
    ffff80278ed50af0 x26ffffa027dd31e0a8 [ 7165.499123] x25ffffa027d9b27f88 x24ffffa027d9b209f8 [7165.504411] x23ffffa027c45b0d60 x22ffff80278ec07c00 [ 7165.509700] x2100020000000000000000000
    ffffa027d9b209f8 [ 7165.514988] x19ffffa027d9b27f88 x18ffffffffffffffff [ 7165.520276] x17
    0000000000000000 x16: 0000000000000000 [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8 [7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067 [ 7165.536140] x11: 0000000000000000 x10:
    0000000000000bb0 [ 7165.541429] x9 ffff00001d6238f0 x8 ffffa027d877af00 [ 7165.546718] x7
    ffffa027d6329600 x6 : ffff7e809f58ca00 [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e [7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000 [ 7165.562583] x1 : 0000000000000000 x0 :
    000000003000188e [ 7165.567872] Call trace: [ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main] [ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas] [ 7165.586876] sas_scsi_recover_host+ 0x134/0x458 [libsas] [7165.592082] scsi_error_handler+0xb4/0x488 [ 7165.596163] kthread+0x134/0x138 [ 7165.599380] ret_from_fork+0x10/0x18 [ 7165.602940] 代碼d5033e9f b9000040 aa0103e2 eb03003f (f9400]0) 7165.609004]從 CPU 75 開始的核心錯誤 (0x1) 通知 [ 7165.700728] ---[ end trace fc042cbbea224efc ]--- [7165.705326] 核心錯誤 - 未同步嚴重例外狀況 若要修正此問題請在遊走 的成員時抓取 sas_dev 鎖定dereg_device_v3_hw() 和 Hisi_sas_release_tasks() 中的 sas_dev.list 以避免在新增和刪除成員的同時進行。時間 ---truncated--- (CVE-2023-53627)

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

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

  - 已解決 Linux 核心中的下列弱點：nvme-tcp: don't access released socket during error recovery While the error recovery work is temporarily failing reconnect attempts, running the 'nvme list' command causes a kernel NULL pointer dereference by calling getsockname() with a released socket. During error recovery work, the nvme tcp socket is released and a new one created, so it is not safe to access the socket without proper check. (CVE-2023-53643)

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

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

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

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

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

  - octeontx2-af藉由新增 MAC 區塊 (例如 CN10K RPM 和 CN10KB RPM_USX) 在存取 cgx 和 lmac 之前新增驗證LMAC 為非連續而 CGX 區塊也為非連續。但是在 RVU 驅動程式初始化期間驅動程式會假設它們是連續的並嘗試以其 id 存取 cgx 或 lmac這會導致核心錯誤。此修補程式透過新增適當的檢查來修正該問題。23.219150[  ] pc : cgx_lmac_read+0x38/0x70 [ 23.219154] lr : rvu_program_channels+0x3f0/0x498 [ 23.223852] sp : ffff000100d6fc80 [ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27: 000000000000005a [23.234288] x26: ffff000102586768 x25 0000000000002500 x24: ffffffffff0f000 (CVE-2023-53654)

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

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

  - drm/i915/gvt修正 remove 中的 vgpu debugfs clean 損毀 vgpu 時仔細檢查可用的 root debugfs例如在移除的情況下drm Minor 的 debugfs root 可能已經損毀進而導致類似以下的核心 oops。主控台切換至色彩虛擬裝置 80x25 i915 0000:00:02.0: MDEV取消註冊 intel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0移除 iommu 群組 14 錯誤核心 NULL 指標解除參照位址000000000000150 PGD 0 P4D 0 Oops0000 [#1] PREEMPT SMP CPU3 PID1046 Commdriverctl 未受污染 6.1.0-rc2+ #6 硬體名稱HP HP ProDesk 600 G3 MT/829DBIOS P02 版本 02.44 2022 年 9 月 13 日 RIP0010:__lock_acquire+0x5e2/0x1f90 代碼87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 49 d0 5b 5d 41 5d 41 5e 41 5f c3 45 31 ff <48> 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0 RSP: 0018:ffff9f770274f948 EFLAGS: 00010046 RAX000003010046 RAX000003010040 RB00000
    0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8895d1173300 R11:
     R120000000000000001  : 0000000000000000 R13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000 FS: 00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000150 CR3: 000000010fd93005 CR400000000003706e0 DR0
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffffe0ff0 DR7: 0000000000000400b 呼叫追踪 <TASK> [0x] lock_200000000400b 呼叫追踪simple_recursive_removal+0xa5/0x2b0 lock_release+0x13d/0x2d0 down_write+0x2a/0xd0 ? simple_recursive_removal+0xa5/0x2b0 simple_recursive_removal+0xa5/0x2b0 start_creating.part.0+0x110/0x110 ? _raw_spin_unlock+0x29/0x40 debugfs_remove+0x40/0x60 intel_gvt_debugfs_remove_vgpu+0x15/0x30 [kvmgt] intel_gvt_destroy_vgpu+0x60/0x100 [kvmgt] intel_vgpu_release_dev+0xe/0x20 [kvmgt] device_release+0x30/0x80 kobject_put+0x79/0x1b0 device_release_driver_internal+0x1b8/0x230 bus_remove_device +0xec/0x160 device_del+0x189/0x400 ? up_write+0x9c/0x1b0 ? mdev_device_remove_common+0x60/0x60 [mdev] mdev_device_remove_common+0x22/0x60 [mdev] mdev_device_remove_cb+0x17/0x20 [mdev] device_for_each_child+0x56/0x80 mdev_unregister_parent+0x5a/0x81 [mdev] intel_gvt_clean_device+0x2d/0xe0 [kvmgt] intel_gvt_driver_remove+0x2e/0xb0 [i915] i915_driver_remove+0xac/0x100 [i915] i915_pci_remove+0x1a/0x30 [i915] pci_device_remove+0x31/0xa0 device_release_driver_internal+0x1b8/0x230 unbind_store+0xd8/0x100 kernfs_fop_write_iter+0x156/0x210 vfs_write+0x236/0x4a0 ksys_write+0x61/0xd0 do_syscall_64 +0x55/0x80 ? find_held_lock+0x2b/0x80 ? lock_release+0x13d/0x2d0 ? up_read+0x17/0x20 ? lock_is_held_type+0xe3/0x140 asm_exc_page_fault+0x22/0x30 ? lockdep_hardirqs_on+0x7d/0x100 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fc9b2c9e0c4 Code: 15 71 7d 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d 3d 05 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48 RSP: 002b:00007ffec29c81c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000d RCX 00007fc9b2c9e0c4 RDX 000000000000000d RSI 0000559f8b5f48a0 RDI
    0000000000000001 RBP: 0000559f8b5f48a0 R08: 0000559f8b5f3540 R09: 00007fc9b2d76d30 R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d R13: 00007fc9b2d77780 R14: 000000000000000d R15:
     </TASK> 00007fc9b2d72a00  Modules linked in: sunrpc intel_rapl_msr intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ee1004 igbvf rapl vfat fat intel_cstate intel_uncore pktcdvd i2c_i801 pcspkr wmi_bmof i2c_smbus acpi_pad vfio_pci vfio_pci_core vfio_virqfd zram fuse dm ---truncated--- (CVE-2023-53625)

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

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

  - 已解決 Linux 核心中的下列弱點：blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping() Our syzkaller report a null pointer dereference, root cause is following:
    __blk_mq_alloc_map_and_rqs set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs blk_mq_alloc_map_and_rqs blk_mq_alloc_rqs // failed due to oom alloc_pages_node // set->tags[hctx_idx] is still NULL blk_mq_free_rqs drv_tags = set->tags[hctx_idx]; // null pointer dereference is triggered blk_mq_clear_rq_mapping(drv_tags, ...) This is because commit 63064be150e4 (blk-mq: Add blk_mq_alloc_map_and_rqs()) merged the two steps: 1) set->tags[hctx_idx] = blk_mq_alloc_rq_map() 2) blk_mq_alloc_rqs(..., set->tags[hctx_idx]) into one step: set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs() Since tags is not initialized yet in this case, fix the problem by checking if tags is NULL pointer in blk_mq_clear_rq_mapping(). (CVE-2022-50530)

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

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

  - hwmon(xgene) 修正 ioremap 和 memremap 洩漏 Smatch 報告drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() 警告 ioremap() 的 ctx->pcc_comm_addr 未於 757 行發布。這是因為在 drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe()、ioremap 和 memremap 中並未釋放可能會造成洩漏。為修正此問題ioremap 和 memremap 已修改為 devm_ioremap 和 devm_memremap。 [groeck
    修正格式和主旨] (CVE-2023-53682)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/i915: Fix system suspend without fbdev being initialized If fbdev is not initialized for some reason - in practice on platforms without display - suspending fbdev should be skipped during system suspend, fix this up. While at it add an assert that suspending fbdev only happens with the display present. This fixes the following: [ 91.227923] PM:
    suspend entry (s2idle) [ 91.254598] Filesystems sync: 0.025 seconds [ 91.270518] Freezing user space processes [ 91.272266] Freezing user space processes completed (elapsed 0.001 seconds) [ 91.272686] OOM killer disabled. [ 91.272872] Freezing remaining freezable tasks [ 91.274295] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 91.659622] BUG: kernel NULL pointer dereference, address:
    00000000000001c8 [ 91.659981] #PF: supervisor write access in kernel mode [ 91.660252] #PF:
    error_code(0x0002) - not-present page [ 91.660511] PGD 0 P4D 0 [ 91.660647] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 91.660875] CPU: 4 PID: 917 Comm: bash Not tainted 6.2.0-rc7+ #54 [ 91.661185] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20221117gitfff6d81270b5-9.fc37 unknown [ 91.661680] RIP:
    0010:mutex_lock+0x19/0x30 [ 91.661914] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 62 d3 ff ff 31 c0 65 48 8b 14 25 00 15 03 00 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b4 0f 1f 40 [ 91.662840] RSP: 0018:ffffa1e8011ffc08 EFLAGS: 00010246 [ 91.663087] RAX:
    0000000000000000 RBX: 00000000000001c8 RCX: 0000000000000000 [ 91.663440] RDX: ffff8be455eb0000 RSI:
    0000000000000001 RDI: 00000000000001c8 [ 91.663802] RBP: ffff8be459440000 R08: ffff8be459441f08 R09:
    ffffffff8e1432c0 [ 91.664167] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [91.664532] R13: 00000000000001c8 R14: 0000000000000000 R15: ffff8be442f4fb20 [ 91.664905] FS:
    00007f28ffc16740(0000) GS:ffff8be4bb900000(0000) knlGS:0000000000000000 [ 91.665334] CS: 0010 DS: 0000 ES:
    0000 CR0: 0000000080050033 [ 91.665626] CR2: 00000000000001c8 CR3: 0000000114926006 CR4: 0000000000770ee0 [ 91.665988] PKRU: 55555554 [ 91.666131] Call Trace: [ 91.666265] <TASK> [ 91.666381] intel_fbdev_set_suspend+0x97/0x1b0 [i915] [ 91.666738] i915_drm_suspend+0xb9/0x100 [i915] [ 91.667029] pci_pm_suspend+0x78/0x170 [ 91.667234] ? __pfx_pci_pm_suspend+0x10/0x10 [ 91.667461] dpm_run_callback+0x47/0x150 [ 91.667673] __device_suspend+0x10a/0x4e0 [ 91.667880] dpm_suspend+0x134/0x270 [ 91.668069] dpm_suspend_start+0x79/0x80 [ 91.668272] suspend_devices_and_enter+0x11b/0x890 [ 91.668526] pm_suspend.cold+0x270/0x2fc [ 91.668737] state_store+0x46/0x90 [ 91.668916] kernfs_fop_write_iter+0x11b/0x200 [ 91.669153] vfs_write+0x1e1/0x3a0 [ 91.669336] ksys_write+0x53/0xd0 [91.669510] do_syscall_64+0x58/0xc0 [ 91.669699] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0 [91.669980] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0 [ 91.670278] ? syscall_exit_to_user_mode+0x17/0x40 [ 91.670524] ? do_syscall_64+0x67/0xc0 [ 91.670717] ?
    __irq_exit_rcu+0x3d/0x140 [ 91.670931] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 91.671202] RIP:
    0033:0x7f28ffd14284 v2: CC stable. (Jani) References:
    https://gitlab.freedesktop.org/drm/intel/-/issues/8015 (cherry picked from commit 9542d708409a41449e99c9a464deb5e062c4bee2) (CVE-2023-53678)

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

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

  - ext4修正 ext4_fname_{setup_filename,prepare_lookup} 中的記憶體洩漏問題。如果檔案名稱大小寫折疊失敗則會洩漏 fscrypt_name 結構 (亦即「crypto_buf.name」成員) 的記憶體。確保我們將其釋放到 ext4_fname_setup_filename() 和 ext4_fname_prepare_lookup() 函式上的錯誤路徑中。 (CVE-2023-53662)

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

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

  - tipc修正 tipc_topsrv_kern_subscr 中的資訊洩漏 使用 8 位元組寫入來初始化 tipc_topsrv_kern_subscr() 中的 sub.usr_handle否則有四個位元組會在發出 setsockopt(..., SOL_TIPC, ...) 時維持未初始化狀態。這會導致 KMSAN 在收到封包時報告資訊洩漏
    ================================================== === 錯誤KMSANcopyout+0xbc/0x100 lib/iov_iter.c:169 tool_copy_to_user ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/iov_iter.c:169 _copy_to_iter+0x5c0 中的核心資訊洩漏/0x20a0 lib/iov_iter.c:527 copy_to_iter ./include/linux/uio.h:176 simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419 skb_copy_datagram_iter +0x58/0x200 net/core/datagram.c:527 skb_copy_datagram_msg ./include/linux/skbuff.h:3903 packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469
    ____sys_recvmsg+0x2c4/0x810 net/socket.c:? ___sys_recvmsg+0x217/0x840 net/socket.c:2743 __sys_recvmsg net/socket.c:2773 __do_sys_recvmsg net/socket.c:2783 __se_sys_recvmsg net/socket.c:2780
    __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry /entry_64.S:120 ... uninit 儲存至記憶體的位置為 tipc_sub_ subscription+0x42d/0xb50 net/tipc/subscr.c:156 tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375 tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipc_group_create +0x4e7/0x7d0 net/tipc/group.c:190 tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084 tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201 __sys_setsockopt+0x87f/0xdc0 net/socket。 c:2252 __do_sys_setsockopt net/socket.c:2263 __se_sys_setsockopt net/socket.c:2260 __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/ x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 本機變數 sub 建立於
    提示...
    ================================================== === (CVE-2022-50531)

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

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

  - blk-mq避免雙重 ->queue_rq() 因為提前逾時 David Jeffery 發現一個雙重 ->queue_rq() 問題到目前為止它可以在 VM 使用案例中觸發這是因為 vCPU pthread 的長 vmexit 延遲或先佔延遲所導致 或vCPU pthread 中發生長頁面錯誤然後在將對硬體的要求排入佇列之前但在 ->queue_rq() 期間呼叫 blk_mq_start_request() 之后區塊 IO req 逾時則逾時處置程式可能會透過重新佇列再重複 ->queue_rq() 的方式來處理會造成核心錯誤。目前為止驅動程式有責任解決逾時和完成之間的爭用問題因此理論上應該在驅動程式中解決假設驅動程式有足夠的知識。但這確實是一個常見問題許多驅動程式可能有類似問題而且可能難以修正所有受影響的驅動程式即使驅動程式不容易處理爭用也是如此。因此 David 建議此修補程式透過排出進行中的 ->queue_rq() 來解決此問題。
    (CVE-2022-50554)

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

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

  - 輸入exc3000 - 關機時正確停止計時器。我們必須在驅動程式解除系結或探查失敗時停止計時器否則會發生 UAF/Oops。 (CVE-2023-53651)

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

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

  - NFSD避免以 ops->opnum == OP_ILLEGAL 呼叫 OPDESC() OPDESC() 只會依 op 的作業編號索引 nfsd4_ops[] 而不檢查該值。假設呼叫者已謹慎避免使用超出邊界的 opnum 值來呼叫它。 nfsd4_decode_compound() 不那麼小心可在 opnum 設為 OP_ILLEGAL (即 10044) 叫用 OPDESC() -- 遠遠超出 nfsd4_ops[]的結尾。 (CVE-2023-53680)

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

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

  - ice在完整設定 switchdev 之前不傳送。當某些資源仍未配置時可能會呼叫 ice_eswitch_port_start_xmit其可造成 NULL 指標解除參照。
    藉由檢查 switchdev 組態是否已完成來修正此問題。 (CVE-2023-53657)

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

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

  - scsitargetiscsi修正 lio_target_nacl_info_show() 中的緩衝區溢位。 lio_target_nacl_info_show() 函式在迴圈中使用 sprintf()來列印工作階段中每個 iSCSI 連線的詳細資料而不檢查緩衝區長度。在足夠 iSCSI 連線的情況下可能會造成 configfs 提供的緩衝區溢位並損毀記憶體。此修補程式以檢查緩衝區邊界的 sysfs_emit_at() 取代 sprintf()。 (CVE-2023-53676)

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

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

  - platform/x86mxm-wmi修正 mxm_wmi_call_mx[ds|mx]() 中的 memleakwmi_evaluate_method() 傳回的 ACPI 緩衝區記憶體 (out.pointer) 在呼叫之後並未釋放因此會導致記憶體洩漏。該方法導致未使用 ACPI 緩衝區因此只需將 NULL 傳遞至 wmi_evaluate_method()其可修正記憶體洩漏。 (CVE-2022-50521)

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

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

  - rcu避免因 __rcu_irq_enter_check_tick() 遭到 kprobe 執行的堆疊溢位。
    __rcu_irq_enter_check_tick() 可造成核心堆疊溢位如下所示。若要重現此問題請啟用 CONFIG_NO_HZ_FULL 並以引數 nohz_full= 開機核心然後在殼層提示下提供下列命令# cd /sys/kernel/tracing/ # echo 'p:mp1
    __rcu_irq_enter_check_tick' >> kprobe_events # echo 1 > Events/kprobes/enable 因此此認可會新增
    __rcu_irq_enter_check_tick() 使用 NOKPROBE_SYMBOL() 複製到 kprobes 黑名單。堆疊空間不足無法處理例外狀況ESR0x00000000f2000004 -- BRK (AArch64) FAR 0x0000ffffccf3e510 工作堆疊
    [0xffff80000ad30000..0xffff80000ad38000] IRQ stack: [0xffff800008050000..0xffff800008058000] Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310] CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19 Hardware name: linux 、dummy-virt (DT) pstate400003c5 (nZcv DAIF -PAN
    -UAO -TCO -DIT -SSBS BTYPE=--) pc : __rcu_irq_enter_check_tick+0x0/0x1b8 lr : ct_nmi_enter+0x11c/0x138 sp : ffff80000ad30080 x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000 x23: 00000000400003c5 x220000ffffccf3e510 x21
    ffff089c36fae148 x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6c x14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12:
    1fffe113804d6809 x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000 x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001 x5 : ffff80000ad30120 x4 : dfff800000000000 x3 :
    ffffa8da8e3016f4 x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000 Kernel panic - not syncing: kernel stack overflow CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19 Hardware name: linux,dummy-virt ( DT) 呼叫追踪dump_backtrace+0xf8/0x108 show_stack+0x20/0x30 dump_stack_lvl+0x68/0x84 dump_stack+0x1c/0x38 panic+0x214/0x404 add_taint+0x0/0xf8 panic_bad_stack+0x144/0x160 handle_bad_stack+0x38/0x58/0x7d_stack+0x78/0x7d_stack+0x78
    __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+ 0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+064/0x68
    __rcu_irq_enter_check_tick+0x0/0x1b8 [...] el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync +0x64/0x68
    __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 el1_interrupt+0x28/0x60 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x64/0x68
    __ftrace_set_clr_event_nolock+0x98/0x198 __ftrace_set_clr_event+0x58/0x80 system_enable_write+0x144/0x178 vfs_write+0x174/0x738 ksys_write+0xd0/0x188 __arm64_sys_write+0x4c/0x60 invoke_syscall+0x64/0x180 el0_svc_common.constprop.0+0x84/0x160 do_el0_svc+0x48/0xe8 el0_svc +0x34/0xd0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x190/0x194 SMP停止次要 CPU 核心位移
    0x28da86000000 來自 0xffff800008000000 PHYS_OFFSET: 0xfffff76600000000 CPU 功能
    0x00000、01a00100、0000421b 記憶體限制無 (CVE-2023-53655)

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

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

  - drm/amdgpu修正 hpd_rx_irq_create_workqueue() 中的記憶體洩漏問題如果處理 hpd_rx_irq 卸載工作的工作佇列陣列建構失敗我們需要回溯。破壞所有已建立的工作佇列以及為 hpd_rx_irq_offload_work_queue 結構陣列配置的記憶體。 (CVE-2022-50515)

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

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

  - xfrm轉儲存 algos 和 encap 時的零填補。將資料複製到使用者空間時我們應確保僅複製有效的資料。結構中的填補可能以隨機 (可能是敏感的) 資料填入且絕不應直接提供給使用者空間。此修補程式可修正 xfrm_user 中的 xfrm 演算法和 encap 範本複制使填補得以歸零。 (CVE-2023-53684)

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

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

  - scsimpt3sas修正 mpt3sas_transport_port_add() 中可能的資源洩漏。在 mpt3sas_transport_port_add() 中如果 sas_rphy_add() 傳回錯誤則需要呼叫 sas_rphy_free() 以釋放 sas_end_device_alloc() 中配置的資源。否則將會發生核心損毀無法處理虛擬位址 0000000000000108 CPU 的核心 NULL 指標解除參照 45 PID37020 Commbash Kdump
    已載入 污染GW 6.1.0-rc1+ #189 pstate 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc
    device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_rphy_remove+0x50/0x78 [scsi_transport_sas] sas_port_delete+ 0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_rphy_remove+0x38/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas ] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] scsih_remove+0xd8/0x420 [mpt3sas] 由於 sas_rphy_add() 失敗時並未呼叫 transport_add_device()因此未新增該裝置。隨後呼叫 sas_rphy_remove() 以移除 remove() 路徑中的裝置時會發生 NULL 指標解除參照。 (CVE-2022-50532)

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

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

  - 已解決 Linux 核心中的下列弱點：OPP: Fix potential null ptr dereference in dev_pm_opp_get_required_pstate() opp pointer is dereferenced before the IS_ERR_OR_NULL() check. Fix it by removing the dereference to cache opp_table and dereference it directly where opp_table is used. This fixes the following smatch warning: drivers/opp/core.c:232 dev_pm_opp_get_required_pstate() warn: variable dereferenced before IS_ERR check 'opp' (see line 230) (CVE-2023-53664)

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

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

  - wifiath9khif_usb修正 emerge_skbs 記憶體洩漏。在 ath9k_hif_usb_rx_stream() 中配置和使用 hif_dev->remain_skb。表示系統只會在下次呼叫 ath9k_hif_usb_rx_stream() 時處理並隨後釋放 (在錯誤路徑中) 已配置的 resty_skb。因此如果因為裝置取消初始化或暫停而在這兩個呼叫之間解除配置 urb則可能下次不會呼叫 ath9k_hif_usb_rx_stream()而洩漏已配置的 resty_skb。我們的本機 Syzkaller 執行個體能夠觸發該問題。當接收邏輯上連結在一起的兩個連續 urb 時remain_skb 才有意義例如第一個 skb 的特定資料欄位指示要配置的快取 skb、memcpy 和一些資料隨後會在下一次 ath9k_hif_usb_rx_stream() 呼叫中處理。Urbs 解除配置應該會使該連結變得不相關因此在這些情況下我們需要釋放快取的 skb。透過引入一個函式來修正此洩漏以在 rx urb 已解除配置時明確釋放剩餘的skb (若其不是 NULL)。當剩餘skb 尚未被配置 (hif_dev 結構為 kzalloced) 時或其下次呼叫 ath9k_hif_usb_rx_stream() 中處理時其為 NULL。
    由 Linux Verification Center (linuxtesting.org) 的 Syzkaller 發現。 (CVE-2023-53641)

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

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

  - gfs2修正 gfs2_show_options() 中可能發生的資料爭用。在 gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ,commit=%d, val);因此可在同時執行 gfs2_show_options() 和其他函式 (如 gfs2_reconfigure()) 時造成資料爭用
    spin_lock(>->gt_spin) gt->gt_logd_secs = newargs->ar_commit為修正這些可能發生的資料爭用鎖定 sdp->sd_tune.gt_spin 會在存取 gfs2_tune 的欄位前取得併在這些存取後釋放。由 Andreas 進行的進一步變更- 不會針對 seq_printf 作業保留微調鎖定。
    (CVE-2023-53622)

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

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

  - 已解決 Linux 核心中的下列弱點：drivers/perf: hisi: Don't migrate perf to the CPU going to teardown The driver needs to migrate the perf context if the current using CPU going to teardown. By the time calling the cpuhp::teardown() callback the cpu_online_mask() hasn't updated yet and still includes the CPU going to teardown. In current driver's implementation we may migrate the context to the teardown CPU and leads to the below calltrace: ... [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008 [ 368.113699][ T932] Call trace: [ 368.116834][ T932]
    __switch_to+0x7c/0xbc [ 368.120924][ T932] __schedule+0x338/0x6f0 [ 368.125098][ T932] schedule+0x50/0xe0 [ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24 [ 368.134229][ T932]
    __mutex_lock.constprop.0+0x1d4/0x5dc [ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30 [ 368.144573][T932] mutex_lock+0x50/0x60 [ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0 [ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu] [ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650 [ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190 [ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0 [368.175099][ T932] kthread+0x108/0x13c [ 368.179012][ T932] ret_from_fork+0x10/0x18 ... Use function cpumask_any_but() to find one correct active cpu to fixes this issue. (CVE-2023-53656)

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

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

  - net/schedsch_fq如果使用值大於 INT_MAX 的初始量檔設定 sch_fq則修正認可的整數溢位(認可的第一個指派會帶正負號的整數溢位為非常負的值)。在此情況下Cristoph 提供的 syzkaller 指令碼會觸發 CPU 軟鎖定警告即使是使用少數通訊端也是如此。這不是無限迴圈但配額不一定應該是每個新流量的負 2Gb。將初始時間片設定為 INT_MAX 經證實可修正該問題。 v2根據 Jakub Kicinski 的建議在 fq_policy 中完成初始量片的驗證而非在 fq_change() 中開放編碼 (CVE-2023-53624)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/i915: Fix memory leaks in i915 selftests This patch fixes memory leaks on error escapes in function fake_get_pages (cherry picked from commit 8bfbdadce85c4c51689da10f39c805a7106d4567) (CVE-2023-53677)

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

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

  - 已解決 Linux 核心中的下列弱點：vdpa: Add features attr to vdpa_nl_policy for nlattr length check The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa features attr to avoid such bugs.
    (CVE-2023-53652)

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

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

  - 已解決 Linux 核心中的下列弱點：dmaengine: qcom-adm: fix wrong sizeof config in slave_config Fix broken slave_config function that uncorrectly compare the peripheral_size with the size of the config pointer instead of the size of the config struct. This cause the crci value to be ignored and cause a kernel panic on any slave that use adm driver. To fix this, compare to the size of the struct and NOT the size of the pointer. (CVE-2022-50540)

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

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

  - tty序列samsung_tty修正反覆 clk 時 s3c24xx_serial_getclk() 中的記憶體洩漏。搜尋最佳 clk 時我們反覆使用所有可能的 clk。如果找到更好的比對則必須釋放先前的比對 (若有)。若已發現較佳相符我們仍需釋放新的相符否則其會洩漏。 (CVE-2023-53687)

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

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

  - 已解決 Linux 核心中的下列弱點：bpf: Make bpf_refcount_acquire fallible for non-owning refs This patch fixes an incorrect assumption made in the original bpf_refcount series [0], specifically that the BPF program calling bpf_refcount_acquire on some node can always guarantee that the node is alive. In that series, the patch adding failure behavior to rbtree_add and list_push_{front, back} breaks this assumption for non-owning references. Consider the following program:
    n = bpf_kptr_xchg(&mapval, NULL); /* skip error checking */ bpf_spin_lock(&l); if(bpf_rbtree_add(&t, &n->rb, less)) { bpf_refcount_acquire(n); /* Failed to add, do something else with the node */ } bpf_spin_unlock(&l); It's incorrect to assume that bpf_refcount_acquire will always succeed in this scenario. bpf_refcount_acquire is being called in a critical section here, but the lock being held is associated with rbtree t, which isn't necessarily the lock associated with the tree that the node is already in. So after bpf_rbtree_add fails to add the node and calls bpf_obj_drop in it, the program has no ownership of the node's lifetime. Therefore the node's refcount can be decr'd to 0 at any time after the failing rbtree_add. If this happens before the refcount_acquire above, the node might be free'd, and regardless refcount_acquire will be incrementing a 0 refcount. Later patches in the series exercise this scenario, resulting in the expected complaint from the kernel (without this patch's changes): refcount_t:
    addition on 0; use-after-free. WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110 Modules linked in: bpf_testmod(O) CPU: 1 PID: 207 Comm: test_progs Tainted: G O 6.3.0-rc7-02231-g723de1a718a2-dirty #371 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP:
    0010:refcount_warn_saturate+0xbc/0x110 Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02 00 75 94 48 c7 c7 e0 13 d2 82 c6 05 4e 64 f6 02 01 e8 64 a3 5c ff <0f> 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7 RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082 RAX: 0000000000000000 RBX:
    0000000000000002 RCX: 0000000000000000 RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680 RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7 R10: ffffed1021722edc R11:
    746e756f63666572 R12: ffff88810027d388 R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048 FS: 00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0 DR0:
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> bpf_refcount_acquire_impl+0xb5/0xc0 (rest of output snipped) The patch addresses this by changing bpf_refcount_acquire_impl to use refcount_inc_not_zero instead of refcount_inc and marking bpf_refcount_acquire KF_RET_NULL. For owning references, though, we know the above scenario is not possible and thus that bpf_refcount_acquire will always succeed. Some verifier bookkeeping is added to track is input owning ref? for bpf_refcount_acquire calls and return false from is_kfunc_ret_null for bpf_refcount_acquire on owning refs despite it being marked KF_RET_NULL. Existing selftests using bpf_refcount_acquire are modified where necessary to NULL-check its return value. [0]:
    https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/ (CVE-2023-53645)

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

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

  - wifi: brcmfmac修正 brcmf_fw_alloc_request() 中潛在的移位超出邊界。此修補程式可修正 brcmfmac 中裝置提供的「chiprev」太大時在 BIT(chiprev) 中發生的移位超出邊界。當我們使用 u32 變數和 BIT(chiprev) 執行位元與運算時其也不應等於或大於 BITS_PER_TYPE(u32)。此修補程式會新增一個檢查可讓函式在此情況下傳回 NULL。
    請注意NULL 情況稍後會由匯流排特定的呼叫端 brcmf_usb_probe_cb() 或 brcmf_usb_reset_resume() 等加以處理。此問題由 syzkaller 的修改版本發現。UBSANdrivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 中的 shift-out-of-bounds 移位指數 151055786 對於 64 位元類型「long unsigned int」CPU: 0 PID: 1885 Commkworker /0:2 污染GO 5.14.0+ #132 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org04/01/2014 工作佇列usb_hub_wq hub_event 呼叫Tracedump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40
    __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 brcmf_usb_reset_resume+0x120/0x120 number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 mark_held_locks+0x9f/0xe0 lockdep_hardirqs_on_prepare+0x273/0x3e0
    _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 wiphy_new_nm+0x1476/0x1d50 kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 real_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 bus_rescan_devices+0x20/0x20 lockdep_hardirqs_on_prepare+0x273/0x3e0 trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 Likewise_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x2?50 driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 bus_rescan_devices+0x20/0x20 lockdep_hardirqs_on_prepare+0x273/0x3e0 trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ?
    __kthread_parkme+0xd9/0x1d0 ? pr ---truncated--- (CVE-2022-50551)

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

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

  - fsdlm修正 midcomms 提交中的釋放後使用在 softirq 內容中處理 dlm 訊息時遇到下列 KASAN 釋放後使用警告[ 151.760477] ============= ================================================== === [ 151.761803] 錯誤KASAN在 dlm_midcomms_commit_mhandle+0x19d/0x4b0 中發生釋放後使用 [ 151.763414] 工作 lock_torture/1347 在位址 ffff88811a980c60 讀取大小 4 [ 151.765284] CPU7 PID1347 通訊lock_torture 未受污染的 6.1.0-rc4+ #2828 [151.766778] 硬體名稱Red Hat KVM/RHEL-AV、BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 2014 年 4 月 1 日 [151.768726]呼叫追踪 [ 151.769277] <TASK> [ 151.769748] dump_stack_lvl+0x5b/0x86 [ 151.770556] print_report+0x180/0x4c8 [ 151.771378] kasan_complete_mode_report_info+0x7c/0x1e0 [ 151.772241] dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.773069] kasan_report+0x93/0x1a0 [ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.774514] __asan_load4+0x7e/0xa0 [ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.775890] create_message.isra.29.constprop.64+0x57/0xc0 [151.776770] send_common+0x19f/0x1b0 [ 151.777342] ? remove_from_waiters+0x60/0x60 [ 151.778017] ? lock_downgrade+0x410/0x410 [ 151.778648] ? __this_cpu_preempt_check+0x13/0x20 [ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0 [ 151.780292] _convert_lock+0x46/0x150 [ 151.780893] convert_lock+0x7b/0xc0 [ 151.781459] dlm_lock+0x3ac/0x580 [ 151.781993] ? 0xffffffffc0540000 [ 151.782522] ? Torch_stop+0x120/0x120 [dlm_locktorture] [ 151.783379] dlm_scan_rsbs+0xa70/0xa70 [ 151.784003] ? preempt_count_sub+0xd6/0x130 [ 151.784661] ? is_module_address+0x47/0x70 [ 151.785309] ? Torch_stop+0x120/0x120 [dlm_locktorture] [ 151.786166] 0xffffffffc0540000 [ 151.786693] ? lockdep_init_map_type+0xc3/0x360 [ 151.787414] ? 0xffffffffc0540000 [ 151.787947] torque_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.789004] ? Torch_stop+0x120/0x120 [dlm_locktorture] [ 151.789858] 0xffffffffc0540000 [ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture] [ 151.791347] delay_tsc+0x94/0xc0 [ 151.791898] torque_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.792735] ? torch_start+0x30/0x30 [dlm_locktorture] [ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture] [ 151.794448] ? Torch_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture] [ 151.795539] lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.796476] do_raw_spin_lock+0x11e/0x1e0 [ 151.797152] ? mark_held_locks+0x34/0xb0 [ 151.797784] ?
    _raw_spin_unlock_irqrestore+0x30/0x70 [ 151.798581] ? __kthread_parkme+0x79/0x110 [ 151.799246] ? trace_preempt_on+0x2a/0xf0 [ 151.799902] ? __kthread_parkme+0x79/0x110 [ 151.800579] ? preempt_count_sub+0xd6/0x130 [ 151.801271] ? __kasan_check_read+0x11/0x20 [ 151.801963] ?
    __kthread_parkme+0xec/0x110 [ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.803569] kthread+0x192/0x1d0 [ 151.804104] ? kthread_complete_and_exit+0x30/0x30 [ 151.804881] ret_from_fork+0x1f/0x30 [ 151.805480] </TASK> [ 151.806111] 由工作 1347 分配[ 151.806681] kasan_save_stack+0x26/0x50 [ 151.807308] kasan_set_track+0x25/0x30 [ 151.807920] kasan_save_alloc_info+0x1e/0x30 [ 151.808609] __kasan_slab_alloc+0x63/0x80 [ 151.809263] kmem_cache_alloc+0x1ad/0x830 [ 151.809916] dlm_allocate_mhandle+0x17/0x20 [ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260 [+x 151.8113445]5/__建立訊息0x180 [ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0 [ 151.812880] send_common+0x129/0x1b0 [ 151.813467]
    _convert_lock+0x46/0x150 [ 151.814074] convert_lock+0x7b/0xc0 [ 151.814648] dlm_lock+0x3ac/0x580 [151.815199] torque_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.816258] torque_ex_iter+0xc3/0xea [dlm_locktorture ] [ 151.817129] lock_t ---truncated--- (CVE-2023-53629)

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

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

  - 已解決 Linux 核心中的下列弱點：bpf, arm64: Fixed a BTI error on returning to patched function When BPF_TRAMP_F_CALL_ORIG is set, BPF trampoline uses BLR to jump back to the instruction next to call site to call the patched function. For BTI-enabled kernel, the instruction next to call site is usually PACIASP, in this case, it's safe to jump back with BLR. But when the call site is not followed by a PACIASP or bti, a BTI exception is triggered. Here is a fault log: Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI CPU: 0 PID: 263 Comm: test_progs Tainted: GF Hardware name: linux,dummy-virt (DT) pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c) pc : bpf_fentry_test1+0xc/0x30 lr : bpf_trampoline_6442573892_0+0x48/0x1000 sp :
    ffff80000c0c3a50 x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050 x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21:
    000000000000000a x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0 x14: 0000000000000000 x13: 0000000000000000 x12:
    0000000000000000 x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101 x5 : 0000000000000000 x4 : 00000000fffffff2 x3 :
    0000000000000001 x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001 Kernel panic - not syncing: Unhandled exception CPU: 0 PID: 263 Comm: test_progs Tainted: GF Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0xec/0x144 show_stack+0x24/0x7c dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x1cc/0x3ec __el0_error_handler_common+0x0/0x130 el1h_64_sync_handler+0x60/0xd0 el1h_64_sync+0x78/0x7c bpf_fentry_test1+0xc/0x30 bpf_fentry_test1+0xc/0x30 bpf_prog_test_run_tracing+0xdc/0x2a0 __sys_bpf+0x438/0x22a0 __arm64_sys_bpf+0x30/0x54 invoke_syscall+0x78/0x110 el0_svc_common.constprop.0+0x6c/0x1d0 do_el0_svc+0x38/0xe0 el0_svc+0x30/0xd0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x1a0/0x1a4 Kernel Offset: disabled CPU features:
    0x0000,00034c24,f994fdab Memory Limit: none And the instruction next to call site of bpf_fentry_test1 is ADD, not PACIASP: <bpf_fentry_test1>: bti c nop nop add w0, w0, #0x1 paciasp For BPF prog, JIT always puts a PACIASP after call site for BTI-enabled kernel, so there is no problem. To fix it, replace BLR with RET to bypass the branch target check. (CVE-2023-53634)

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

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

  - 已解決 Linux 核心中的下列弱點：iommufd: Fix unpinning of pages when an access is present syzkaller found that the calculation of batch_last_index should use 'start_index' since at input to this function the batch is either empty or it has already been adjusted to cross any accesses so it will start at the point we are unmapping from. Getting this wrong causes the unmap to run over the end of the pages which corrupts pages that were never mapped. In most cases this triggers the num pinned debugging: WARNING: CPU: 0 PID: 557 at drivers/iommu/iommufd/pages.c:294
    __iopt_area_unfill_domain+0x152/0x560 Modules linked in: CPU: 0 PID: 557 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__iopt_area_unfill_domain+0x152/0x560 Code: d2 0f ff 44 8b 64 24 54 48 8b 44 24 48 31 ff 44 89 e6 48 89 44 24 38 e8 fc d3 0f ff 45 85 e4 0f 85 eb 01 00 00 e8 0e d2 0f ff <0f> 0b e8 07 d2 0f ff 48 8b 44 24 38 89 5c 24 58 89 18 8b 44 24 54 RSP:
    0018:ffffc9000108baf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000ffffffff RCX: ffffffff821e3f85 RDX: 0000000000000000 RSI: ffff88800faf0000 RDI: 0000000000000002 RBP: ffffc9000108bd18 R08:
    000000000003ca25 R09: 0000000000000014 R10: 000000000003ca00 R11: 0000000000000024 R12: 0000000000000004 R13: 0000000000000801 R14: 00000000000007ff R15: 0000000000000800 FS: 00007f3499ce1740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000020000243 CR3: 00000000179c2001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> iopt_area_unfill_domain+0x32/0x40 iopt_table_remove_domain+0x23f/0x4c0 iommufd_device_selftest_detach+0x3a/0x90 iommufd_selftest_destroy+0x55/0x70 iommufd_object_destroy_user+0xce/0x130 iommufd_destroy+0xa2/0xc0 iommufd_fops_ioctl+0x206/0x330
    __x64_sys_ioctl+0x10e/0x160 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Also add some useful WARN_ON sanity checks. (CVE-2023-53630)

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

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

  - 已解決 Linux 核心中的下列弱點：octeon_ep: cancel queued works in probe error path If it fails to get the devices's MAC address, octep_probe exits while leaving the delayed work intr_poll_task queued. When the work later runs, it's a use after free. Move the cancelation of intr_poll_task from octep_remove into octep_device_cleanup. This does not change anything in the octep_remove flow, but octep_device_cleanup is called also in the octep_probe error path, where the cancelation is needed. Note that the cancelation of ctrl_mbox_task has to follow intr_poll_task's, because the ctrl_mbox_task may be queued by intr_poll_task. (CVE-2023-53638)

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

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

  - md修正 status_resync 中的軟鎖定 status_resync() 將計算 'curr_resync - recovery_active' 以向使用者顯示如下進度列[============>........] resync = 61.4%「curr_resync」和「recovery_active」已在 md_do_sync() 中更新status_resync() 可以並行讀取它們因此「curr_resync - recovery_active」可能會溢位為一個巨大數字。在此情況下status_resync() 會停滯在列印大量「=」的迴圈中進而導致軟鎖定。在此情況下將「重新同步」設定為 MD_RESYNC_ACTIVE 可修正此問題如此便可將進行中的重新同步報告給使用者。 (CVE-2023-53620)

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

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

  - lib/fonts修正位元移位中未定義的行為 get_default_font 將已簽署的 32 位元值移位 31 位元並未定義因此將有效位元變更為無正負號。如下所示的 UBSAN 警告呼叫追踪 UBSAN
    lib/fonts/fonts.c:139:20 中的 shift-out-of-bounds 無法以 'int' 類型表示左移 1 位移 1 位置 <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/ 0x4e
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c get_default_font+0x1c7/0x1f0 fbcon_startup+0x347/0x3a0 do_take_over_console+0xce/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0
    __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 real_probe+0x181/0x550
    __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190
    __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190
    __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> (CVE-2022-50511)

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

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

  - drm/amdkfd修正記憶體洩漏此修補程式可修正 中的潛在記憶體洩漏和 seg 錯誤
    _gpuvm_import_dmabuf() 函式 (CVE-2022-50528)

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

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

  - mm/swap修正 swapoff 和 get_swap_pages() 之間的 swap_info_struct 爭用當從可用清單中刪除 si 時必須保留 si->lock。否則其他執行緒可將 si 重新新增至可用清單其可導致記憶體損毀。我們發現唯一發生此情況的地方是 swapoff 路徑。此情況可描述如下核心 0 核心 1 swapoff del_from_avail_list(si) waiting try lock si->lock 取得 swap_avail_lock and re-add si into swap_avail_head 取得 si->lockbut遺漏的 si已經在重新新增並繼續清除SWP_WRITEOK 等可以很容易地發現某些特殊情況可在 get_swap_pages() 內觸發大量警告訊息例如我們同時在接觸的記憶體上呼叫 madvise(MADV_PAGEOUT)同時執行大量 swapon-swapoff 作業 (例如stress- ng-swap)。不過在最糟的情況下上述狀況也可造成不穩定。在 swapoff() 中si 使用的記憶體在關閉交換之後可能會保留在 swap_info[] 中。這表示在針對 swapon 路徑中的新交換區進行配置和重設之前不會立即造成記憶體損毀。錯誤訊息所造成 (CONFIG_PLIST_DEBUG 啟用) ------------[cut here ]------------ top
    00000000e58a3003、n0000000013e75cda、p000000008cd4451a 上一個 0000000035b1e58a、n000000008cd4451a、p
    000000002150ee8d next000000008cd4451a、n 000000008cd4451a、p 000000008cd4451a 警告 CPU 21 PID
    1843lib/plist.c:60 plist_check_prev_next_node+0x50/0x70 模組連結於rfkill(E) crct10dif_ce(E)... CPU21 PID1843 Comm:stress-ng Kdump... 5.10.134+ 硬體名稱Alibaba Cloud ECSBIOS 0.0.0 2015 年 2 月 6 日 pstate 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=-- ) pc
    plist_check_prev_next_node+0x50/0x70 lr plist_check_prev_next_node+0x50/0x70 sp ffff0018009d3c30 x29
    ffff0018009d3c40 x28: ffff800011b32a98 x27: 0000000000000000 x26: ffff001803908000 x25: ffff8000128ea088 x24: ffff800011b32a48 x23: 0000000000000028 x22: ffff001800875c00 x21: ffff800010f9e520 x20:
    ffff001800875c00 x19: ffff001800fdc6e0 x18: 0000000000000030 x17: 0000000000000000 x16: 0000000000000000 x15: 0736076307640766 x14: 0730073007380731 x13: 0736076307640766 x12: 0730073007380731 x11:
    000000000004058d x10: 0000000085a85b76 x9 : ffff8000101436e4 x8 : ffff800011c8ce08 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff0017df9ed338 x4 : 0000000000000001 x3 : ffff8017ce62a000 x2 :
    ffff0017df9ed340 x1 0000000000000000 x0 0000000000000000 呼叫追踪
    plist_check_prev_next_node+0x50/0x70 plist_check_head+0x80/0xf0 plist_add+0x28/0x140 add_to_avail_list+0x9c/0xf0 _enable_swap_info+0x78/0xb4 __do_sys_swapon+0x918/0xa10
    __arm64_sys_swapon+0x20/0x30 el0_svc_common+0x8c/0x220 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180 irq 事件戳記：2082270 呼叫to'del' 現在開始 (從已鎖定的清單開始)請確認其他執行緒看到 si 已同時刪除且 SWP_WRITEOK 清除後才不會再次重新插入。此問題存在於穩定版 5.10.y 之後的版本中。
    (CVE-2023-53623)

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

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

  - ARMOMAP2+omap4-common修正 refcount 洩漏錯誤。在 omap4_sram_init() 中of_find_compatible_node() 會傳回 refcount 遞增的節點指標。當不再使用 of_node_put() 時應予以使用。
    (CVE-2022-50539)

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

ID	名稱	嚴重性
270209	Linux Distros 未修補的弱點：CVE-2025-11561	high
270208	Linux Distros 未修補的弱點：CVE-2025-39961	high
270207	Linux Distros 未修補的弱點：CVE-2025-39957	medium
270206	Linux Distros 未修補的弱點：CVE-2025-39958	high
270205	Linux Distros 未修補的弱點：CVE-2025-39963	high
270204	Linux Distros 未修補的弱點：CVE-2025-39956	medium
270203	Linux Distros 未修補的弱點：CVE-2025-39955	high
270202	Linux Distros 未修補的弱點：CVE-2022-50553	high
270201	Linux Distros 未修補的弱點：CVE-2023-53635	medium
270200	Linux Distros 未修補的弱點：CVE-2022-50510	high
270199	Linux Distros 未修補的弱點：CVE-2023-53627	medium
270198	Linux Distros 未修補的弱點：CVE-2023-53643	medium
270197	Linux Distros 未修補的弱點：CVE-2022-50520	medium
270196	Linux Distros 未修補的弱點：CVE-2023-53654	medium
270195	Linux Distros 未修補的弱點：CVE-2023-53625	medium
270194	Linux Distros 未修補的弱點：CVE-2022-50530	medium
270193	Linux Distros 未修補的弱點：CVE-2023-53682	medium
270192	Linux Distros 未修補的弱點：CVE-2023-53678	medium
270191	Linux Distros 未修補的弱點：CVE-2023-53662	medium
270190	Linux Distros 未修補的弱點：CVE-2022-50531	high
270189	Linux Distros 未修補的弱點：CVE-2022-50554	medium
270188	Linux Distros 未修補的弱點：CVE-2023-53651	medium
270187	Linux Distros 未修補的弱點：CVE-2023-53680	medium
270186	Linux Distros 未修補的弱點：CVE-2023-53657	medium
270185	Linux Distros 未修補的弱點：CVE-2023-53676	high
270184	Linux Distros 未修補的弱點：CVE-2022-50521	medium
270183	Linux Distros 未修補的弱點：CVE-2023-53655	high
270182	Linux Distros 未修補的弱點：CVE-2022-50515	medium
270181	Linux Distros 未修補的弱點：CVE-2023-53684	high
270180	Linux Distros 未修補的弱點：CVE-2022-50532	medium
270179	Linux Distros 未修補的弱點：CVE-2023-53664	medium
270178	Linux Distros 未修補的弱點：CVE-2023-53641	medium
270177	Linux Distros 未修補的弱點：CVE-2023-53622	medium
270176	Linux Distros 未修補的弱點：CVE-2023-53656	medium
270175	Linux Distros 未修補的弱點：CVE-2023-53624	medium
270174	Linux Distros 未修補的弱點：CVE-2023-53677	medium
270173	Linux Distros 未修補的弱點：CVE-2023-53652	medium
270172	Linux Distros 未修補的弱點：CVE-2022-50540	medium
270171	Linux Distros 未修補的弱點：CVE-2023-53687	medium
270170	Linux Distros 未修補的弱點：CVE-2023-53645	high
270169	Linux Distros 未修補的弱點：CVE-2022-50551	medium
270168	Linux Distros 未修補的弱點：CVE-2023-53629	high
270167	Linux Distros 未修補的弱點：CVE-2023-53634	medium
270166	Linux Distros 未修補的弱點：CVE-2023-53630	high
270165	Linux Distros 未修補的弱點：CVE-2023-53638	medium
270164	Linux Distros 未修補的弱點：CVE-2023-53620	medium
270163	Linux Distros 未修補的弱點：CVE-2022-50511	high
270162	Linux Distros 未修補的弱點：CVE-2022-50528	high
270161	Linux Distros 未修補的弱點：CVE-2023-53623	medium
270160	Linux Distros 未修補的弱點：CVE-2022-50539	medium

偵測

Nessus 的 Misc. 系列

high

high

medium

high

high

medium

high

high

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

high

medium

high

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

high

medium

high

medium

medium

high

high

medium

medium