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

  - 在 LemonLDAP::NG 2.16.7 之前的版本和 2.21.3 之前的 2.17 至 2.21 版中，Safe jail 中可能發生 OS 命令插入。它不會在規則評估期間將 _ 本地化。因此，可編輯 Safe jail 評估規則的系統管理員可在伺服器上執行命令。(CVE-2025-59518)

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

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

  - 已解決 Linux 核心中的下列弱點：skbuff: Account for tail adjustment during pull operations Extending the tail can have some unexpected side effects if a program uses a helper like BPF_FUNC_skb_pull_data to read partial content beyond the head skb headlen when all the skbs in the gso frag_list are linear with no head_frag - kernel BUG at net/core/skbuff.c:4219! pc :
    skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c
    __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60 Fix this by marking these skbs as GSO_DODGY so segmentation can handle the tail updates accordingly. (CVE-2022-50365)

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

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

  - block輪詢 Wei 報告使用輪詢 IOPGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0 Oops 0000 [#1] SMP CPU 0 PID 21915 Comm 發生應用程式損毀時檢查 NULL bdev 時更加小心iocore_0 Kdump 已載入 受污染的 GS 5.12.0-0_fbk12_clang_7346_g1bb6f2e7058f #1 硬體名稱Wiwynn Delta Lake MP T8/Delta Lake-Class2BIOS Y3DLM08 2022 年 4 月 10 日 RIP 0010:bio_poll+0x25/0x200 程式碼0f 1f 44 00 000f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 <48> 8b 80 4 6 6 00 500 8 34 31 db 83 fd ff 75 25 65 RSP
    0018:ffffc90005fafdf8 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600 RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140 RBP: ffff88849964df78 R08:
     R090000000000000000  : 0000000000000008 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00 R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001 FS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: iocb_bio_iopoll+0x1d/0x30 io_do_iopoll+0xac/0x250 __se_sys_io_uring_enter+0x3c5/0x5a0 ?
    __x64_sys_write+0x89/0xd0 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP
    0033:0x94f225d 程式碼 24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 05 ] c 0 0 0 0 05 <85> 0f 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7 RSP: 002b:00007fd194ffcd88 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa RAXffffffRBffffffX
    00007fd194ffcdc0 RCX: 00000000094f225d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007 RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000001 R11:
    0000000000000202 R1200007fd269d68030 R130000000000000000 R140000000000000001 R150000000000000000這是因為 bio->bi_bdev 為 NULL 所致。如果我們有兩個工作執行輪詢 IO且在共用輪詢佇列的情況下工作 B 最後會完成來自工作 A 的 IO則可能會發生此情況。如果工作 B 完成 IO 並將 bio 放入我們的快取中則它可以在工作 A 完成輪詢之前再次配置該 bio。由於這將需要在兩個工作之間進行先佔因此在檢查 bio->bi_bdev 是否為 NULL 時稍微小心一點就足夠了。 (CVE-2023-53366)

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

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

  - Rapidio修正 rio_add_device() 失敗時可能發生的名稱洩漏。Patch 系列 Rapidio修正三個可能發生的記憶體洩漏。此修補程式集可修正錯誤處理中的三個名稱洩漏。 - 修補程式 #1 可修正 rio_add_device() 失敗時的兩個名稱洩漏問題。 - 修補程式 #2 可在 rio_register_mport() 失敗時修正名稱洩漏。此修補程式 (共 2 個)如果 rio_add_device() 傳回錯誤則需要釋放 dev_set_name() 配置的名稱。它應該使用 put_device() 來放棄錯誤路徑中的參照以便在 kobject_cleanup() 中釋放名稱並在 rio_release_dev() 中釋放「rdev」。 (CVE-2022-50343)

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

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

  - brcmfmac從 dongle 取得無效的 max_flowrings 時傳回錯誤。如果韌體在初始化時觸發設陷則主機會從 dongle 讀取異常的 max_flowrings 數量而且會在執行 iowrite 以初始化 dongle ring 時造成核心錯誤。若要及早偵測此錯誤我們會在取得無效的 max_flowrings(>256) 時直接傳回錯誤。 (CVE-2022-50358)

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

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

  - usbdwc3核心修正探查中的一些洩漏dwc3_get_properties() 函式呼叫dwc->usb_psy = power_supply_get_by_name(usb_psy_name)因此需要對這些錯誤路徑進行一些額外的清理。 (CVE-2022-50357)

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

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

  - fbdev/ep93xx-fb不指派給結構 fb_info.dev 不將 Linux 裝置評估給結構 fb_info.dev。
    register_framebuffer() 呼叫會初始化 fbdev 裝置的欄位。驅動程式不應覆寫其值。修正驅動程式未正確減少硬體裝置參照計數器並洩漏 fbdev 裝置的錯誤。 v2* 新增修正標籤 (Dan) (CVE-2023-53314)

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

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

  - nilfs2修正透過 iput 使 inode 變髒的 nilfs_root 的釋放後使用。在 nilfs2 的卸載處理程序期間nilfs2 在 nilfs_detach_log_writer() 中卸離其寫入器後沒有任何項目會保留 nilfs_root 結構。
    之前如果 inode 留在garbage_list 中並由 nilfs_detach_log_writer() 結尾的 nilfs_dispose_list 釋放則 nilfs_evict_inode() 可造成 nilfs_root 釋放後使用() 且此錯誤已由提交 9b5a04ac3ad9 修正 (nilfs2釋放後使用修正nilfs_evict_inode() 中 nilfs_root 的錯誤。
    但是發現在從 iput() 呼叫 mark_inode_dirty_sync() 的呼叫路徑中有 UAF 的另一種可能性nilfs_detach_log_writer() nilfs_dispose_list() iput() mark_inode_dirty_sync() __mark_inode_dirty() nilfs_dirty_inode() __nilfs_mark_inode_dirty() nilfs_load_inode_block( ) --> 造成 nilfs_root 結構的 UAF此可能發生在認可 0ae45f63d4ef (vfs新增 lazytime 掛載選項的支援)之後如果 i_state 具有 I_DIRTY_TIME 旗標且 i_nlink 為非-zero。此問題在使用 syzbot 複製器時在提交 28a65b49eb53 (nilfs2降級為唯讀後不寫入已變更的資料) 之後出現但此問題之前可能存在過。透過將清除旗標新增至 nilfs 結構、在處置gargage_list 時設定該旗標並將其簽入
    __nilfs_mark_inode_dirty()。不同於提交 9b5a04ac3ad9 (nilfs2修正 nilfs_evict_inode() 中 nilfs_root 的釋放後使用錯誤)此修補程式不依賴 ns_writer 來判斷是否要略過作業以免在掛載時中斷復原。nilfs_salvage_orphan_logs 常式會在附加記錄寫入器之前弄髒回收資料的緩衝區因此在 ns_writer 為 NULL 時變更 __nilfs_mark_inode_dirty() 以略過作業會造成複原寫入失敗。使用 cleanup-only 旗標的目的是為了縮小此類情況的範圍。 (CVE-2023-53311)

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

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

  - 已解決 Linux 核心中的下列弱點：rxrpc: Fix potential data race in rxrpc_wait_to_be_connected() Inside the loop in rxrpc_wait_to_be_connected() it checks call->error to see if it should exit the loop without first checking the call state. This is probably safe as if call->error is set, the call is dead anyway, but we should probably wait for the call state to have been set to completion first, lest it cause surprise on the way out. Fix this by only accessing call->error if the call is complete. We don't actually need to access the error inside the loop as we'll do that after. This caused the following report: BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1: rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22 rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479 rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714 rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline] rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350 rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464 rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461 kthread+0x1ac/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0:
    rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296 rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726 rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501 ___sys_sendmsg net/socket.c:2555 [inline] __sys_sendmmsg+0x263/0x500 net/socket.c:2641 __do_sys_sendmmsg net/socket.c:2670 [inline] __se_sys_sendmmsg net/socket.c:2667 [inline] __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x00000000 -> 0xffffffea (CVE-2023-53345)

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

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

  - drm/amdkfd修正 kfd_process_device_init_vm 錯誤處理應只損毀 ib_mem並讓處理程序清理背景工作釋放待處理的 BO。重設 pdd->qpd 結構中的指標以避免處理程序損毀背景工作中發生 NULL 指標存取。BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace: amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu] kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu] kfd_process_destroy_pdds+0x71/0x190 [amdgpu] kfd_process_wq_release+0x2a2/0x3b0 [amdgpu] process_one_work+0x2a1/0x600 worker_thread+0x39/0x3d0 (CVE-2022-50354)

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

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

  - trace/blktrace使用 debugfs_lookup() 修正記憶體洩漏。呼叫 debugfs_lookup() 時結果必須有呼叫 dput() 否則記憶體會隨著時間推移而洩漏。為使事情變得更簡單只要呼叫 debugfs_lookup_and_remove() 而不是它會立即處理所有邏輯。 (CVE-2023-53408)

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

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

  - ASoCmediatekmt8183修正 mt8183_mt6358_ts3a227_max98357_dev_probe() 中的 refcount 洩漏。of_parse_phandle() 傳回的節點包含已遞增的 refcount()且在完成使用時必須呼叫 of_node_put()。因此將其新增到 mt8183_mt6358_ts3a227_max98357_dev_probe() 的錯誤路徑中。 (CVE-2022-50392)

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

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

  - netdcb選擇正確的原則來剖析 DCB_ATTR_BCN。dcbnl_bcn_setcfg 使用錯誤的原則來剖析 tb[DCB_ATTR_BCN]這是在認可 859ee3c43812 中引入的問題 (DCB新增對 DCB BCN 的支援)。請參閱以下程式碼中的註解 static int dcbnl_bcn_setcfg(...) { ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_nest for attributes // DCB_PFC_UP_ATTR_0 in enum dcbnl_pfc_up_attrs ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7;
    i++) { // !!! 列舉中的 DCB_BCN_ATTR_RP_0 到 DCB_BCN_ATTR_RP_7 dcbnl_bcn_attrs ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { // !!! 列舉中的 DCB_BCN_ATTR_BCNA_0 到 DCB_BCN_ATTR_RI dcbnl_bcn_attrs ... value_int = nla_get_u32(data[i]); ... } ... } 也就是說nla_parse_nested_deprecated 使用 dcbnl_pfc_up_nest 屬性來剖析 dcbnl_pfc_up_attrs 中定義的 nlattr。但是下列存取程式碼會擷取每個 nlattr 作為 dcbnl_bcn_attrs 屬性。查閱 dcbnl_bcn_attrs 的相關 nla_policy。我們可以發現這兩個原則的開頭部分是相同的。 static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = { .type = NLA_U8}、[DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}、[DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}、[DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}、[DCB_PFC_UP_ATTR_7] = {.type = NLA_U8}、 [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG}, } static const struct nla_policy dcbnl_bcn_nest[...] = {[DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_3] = { .type = NLA_U8}、[DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}、[DCB_BCN_ATTR_RP_7] = {.type = NLA_U8} [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // 和 有所不同 [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG}, }因此目前的程式碼錯誤且此 nla_parse_nested_deprecated 可造成 dcbnl_pfc_up_nest 溢位並使用相鄰的 nla_policy 剖析來自 DCB_BCN_ATTR_BCNA_0 的屬性。因此使用正確的原則 dcbnl_bcn_nest 來剖析巢狀 tb[DCB_ATTR_BCN] TLV。 (CVE-2023-53369)

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

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

  - nvme修正啟用 blktrace 時排清要求造成的多路徑損毀。由 blk_kick_flush 初始化的排清要求具有 NULL bio 且可在 io 完成期間以 nvme_end_req 處理。啟用 blktrace 時在多重路徑已啟動的情況下 nvme_trace_bio_complete 嘗試從排清要求存取 NULL 指標 bio 時會導致下列損毀[ 2517.831677] 錯誤核心 NULL 指標解除參照解決
    000000000000001a [ 2517.835213] #PF核心模式中的監督讀取存取權 [ 2517.838724] #PF
    error_code(0x0000) - 不存在頁面 [ 2517.842222] PGD 7b2d51067 P4D 0 [ 2517.845684] Oops: 0000 [#1] SMP NOPTI [ 2517.849125] CPU2 PID732 Commkworker/2:1H Kdump 已載入受污染的 GS 5.15.67-0.cl9.x86_64 #1 [ 2517.852723] 硬體名稱XFUSION 2288H V6/BC13MBSBC、BIOS 1.13 2022 年 7 月 27 日 [2517.856358] 工作佇列 nvme_tcp_wq nvme_tcp_io_work [nvme_tcp] [ 2517.859993] RIP
    0010:blk_add_trace_bio_complete+0x6/0x30 [ 2517.863628] 代碼1f 44 00 00 48 8b 46 08 31 c9 ba 04 00 10 00 48 8b 80 50 03 00 00 48 8b 78 50 e9 e5 fe ff 0 0 0f 1f 44 54 49 89 f4 55 <0f> b6 7a 1a 48 89 d5 e8 3e 1c 2b 00 48 89 ee 4c 89 e7 5d 89 c1 ba [ 2517.871269] RSP: 0018:ff7f6a008d9dbcd0 EFLAGS: 00010286 [2517.875081] RAX: ff3d5b4be00b1d50 RBX: 0000000002040002 RCXff3d5b0a270f2000 [ 2517.878966] RDX
    0000000000000000 RSIff3d5b0b021fb9f8 RDI 0000000000000000 [ 2517.882849] RBPff3d5b0b96a6fa00 R08
    0000000000000001 R090000000000000000 [ 2517.886718] R10000000000000000c R11000000000000000c R12
    ff3d5b0b021fb9f8 [ 2517.890575] R13: 0000000002000000 R14: ff3d5b0b021fb1b0 R15: 0000000000000018 [2517.894434] FS: 0000000000000000(0000) GS:ff3d5b42bfc80000(0000) knlGS:0000000000000000 [ 2517.898299] CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 [ 2517.902157] CR2000000000000001a CR3
    00000004f023e005 CR40000000000771ee0 [ 2517.906053] DR00000000000000000 DR10000000000000000 DR2
    0000000000000000 [ 2517.909930] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2517.913761] PKRU: 55555554 [ 2517.917558] Call Trace: [ 2517.921294] <TASK> [ 2517.924982] nvme_complete_rq+0x1c3/0x1e0 [nvme_core] [ 2517.928715] nvme_tcp_recv_pdu+0x4d7/0x540 [nvme_tcp] [2517.932442] nvme_tcp_recv_skb+0x4f/0x240 [nvme_tcp] [ 2517.936137] ? nvme_tcp_recv_pdu+0x540/0x540 [nvme_tcp] [ 2517.939830] tcp_read_sock+0x9c/0x260 [ 2517.943486] nvme_tcp_try_recv+0x65/0xa0 [nvme_tcp] [2517.947173] nvme_tcp_io_work+0x64/0x90 [nvme_tcp] [ 2517.950834] process_one_work+0x1e8/0x390 [2517.954473] worker_thread+0x53/0x3c0 [ 2517.958069] ? process_one_work+0x390/0x390 [ 2517.961655] kthread+0x10c/0x130 [ 2517.965211] ? set_kthread_struct+0x40/0x40 [ 2517.968760] ret_from_fork+0x1f/0x30 [2517.972285] </TASK> 若要避免這種情況請在呼叫 trace_block_bio_complete 之前對 req->bio 新增 NULL 檢查。 (CVE-2022-50388)

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

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

  - shmem針對 ramfs 型 tmpfs 的 kill_sb 方法使用 ramfs_kill_sb()。由於 ramfs 型 tmpfs 針對 init_fs_context 方法使用 ramfs_init_fs_context()而這會分配 fc->s_fs_info因此請使用 ramfs_kill_sb() 將其釋放並避免記憶體洩漏。 (CVE-2023-53391)

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

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

  - 已解決 Linux 核心中的下列弱點：md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request There are two check of 'mreplace' in raid10_sync_request(). In the first check, 'need_replace' will be set and 'mreplace' will be used later if no-Faulty 'mreplace' exists, In the second check, 'mreplace' will be set to NULL if it is Faulty, but 'need_replace' will not be changed accordingly. null-ptr-deref occurs if Faulty is set between two check. Fix it by merging two checks into one. And replace 'need_replace' with 'mreplace' because their values are always the same. (CVE-2023-53380)

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

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

  - USBULPI修正使用 debugfs_lookup() 發生的記憶體洩漏。呼叫 debugfs_lookup() 時結果必須有呼叫 dput() 否則記憶體會隨著時間推移而洩漏。為使事情變得更簡單只要呼叫 debugfs_lookup_and_remove() 而不是它會立即處理所有邏輯。 (CVE-2023-53410)

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

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

  - kernel/printk/index.c使用 debugfs_lookup() 修正記憶體洩漏。呼叫 debugfs_lookup() 時結果必須有呼叫 dput() 否則記憶體會隨著時間推移而洩漏。為使事情變得更簡單只要呼叫 debugfs_lookup_and_remove() 而不是它會立即處理所有邏輯。 (CVE-2023-53402)

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

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

  - scsi: ufs: core修正裝置管理 cmd 逾時流程。在 UFS 錯誤處理流程中主機會將裝置管理 cmd (NOP OUT) 傳送至裝置以進行連結復原。如果此 cmd 逾時且清除門鈴失敗則 ufshcd_wait_for_dev_cmd() 將不執行任何動作並傳回。 hba->dev_cmd.complete 結構未設為 NULL。發生此情況時如果裝置已完成 cmd則我們會在
    __ufshcd_transfer_req_compl()。由於完整結構是在堆疊上配置因此會發生下列損毀 ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync +0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork +0x10/0x30 (CVE-2023-53387)

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

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

  - drm/amdgpu使用未鎖定的迭代器 SDMA 更新可能會從未鎖定的內容中呼叫 SDMA 更新頁面表格這會產生以下警告。使用未鎖定的 iterator 來處理此情況。警告 CPU: 0 PID: 1475 at drivers/dma-buf/dma-resv.c:483 dma_resv_iter_next 呼叫追踪dma_resv_iter_first+0x43/0xa0 amdgpu_vm_sdma_update+0x69/0x2d0 [amdgpu] amdgpu_vm_ptes_update+0x29c/0x870 [dgpuvm_update_ampux0d2gpuvm_update+0x2d0] /0x6c0 [amdgpu] svm_range_unmap_from_gpus+0x115/0x300 [amdgpu] svm_range_cpu_invalidate_pagetables+0x510/0x5e0 [amdgpu] __mmu_notifier_invalidate_range_start+0x1d3/0x230 unmap_vmas+0x140/0x150 unmap_region+CVE-2022-503930xa

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

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

  - i2cismt修正 ismt_access() 中的超出邊界錯誤。驅動程式未檢查使用者的資料時變數 'data->block[0]' 可能會非常大而造成超出邊界- 邊界錯誤。下列記錄可能會洩漏此問題[ 33.995542] i2c i2c-1ioctl、 cmd=0x720、 arg=0x7ffcb3dc3a20 [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE [ 33.996475] ========= ================================================== ======= [ 33.996995] 錯誤KASANismt_access.cold+0x374/0x214b 中的超出邊界 [ 33.997473] 任務 ismt_poc/485 在 addr ffff88810efcfdb1 讀取大小為 18446744073709551615 的內容 [ 33.999450] 呼叫追踪[ 34.001849] memcpy+0x20/0x60 [ 34.002077] ismt_access.cold+0x374/0x214b [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0 [ 34.004007] i2c_smbus_xfer+0x10a/0x390 [ 34.004291] i2cdev_ioctl_smbus [+0x2c8/0x70 34.005196] ] ] i2cdev_ioctl+0x5ec/0x74c 先檢查 'data->block[0]' 的大小以修正此錯誤。 (CVE-2022-50394)

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

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

  - netsched修正 tcindex_set_parms 中的記憶體洩漏 Syzkaller 報告如下記憶體洩漏
    ==================================== 錯誤記憶體洩漏未參照物件 0xffff88810c287f00 (大小 256)
    comm syz-executor105、pid 3600、jiffies 4294943292 (12.990s 時效) 十六進位轉儲存 (前 32 個位元組)00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ 反向追踪 [<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/ slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [內嵌] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [內嵌] [<ffffffff839c9e07>] kcalloc include/linux/slab。 h:659 [內嵌] [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [內嵌] [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [<ffffffff839eba67>] netlink_rcv_skb +0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [內嵌] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c :1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [內嵌] [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>]
    ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>]
    __do_sys_sendmmsg net/socket.c:2651 [內嵌] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [內嵌] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>] do_syscall_x64 arch/x86 /entry/common.c:50 [內嵌] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ========== ========================== 核心使用 tcindex_change() 變更現有的篩選內容。
    然而問題在於在變更的過程中若從「p->perfect」擷取「old_r」則核心會使用 tcindex_alloc_perfect_hash() 來新配置篩選結果使用 tcindex_filter_result_init() 清除舊的篩選結果破壞其 tcf_exts 結構進而觸發上述記憶體洩漏。根據 tcindex_lookup() 的說明確切地說「old_r」只有兩個來源。 `old_r` 是從 `p->perfect` 擷取或 `old_r` 是從 `p->h` 擷取。 * 如果是從 `p->perfect` 擷取 `old_r`核心會使用 tcindex_alloc_perfect_hash() 來新配置篩選結果。然後 `r` 會以新配置的 `cp->perfect + handle` 指派。
    因此條件 `old_r && old_r != r` 在此情況下為 true且核心會使用 tcindex_filter_result_init() 清除舊的篩選結果而不損毀其 tcf_exts 結構 * 如果是從 `p->h` 擷取 `old_r`則根據 tcindex_lookup()「p->perfect」為 NULL。考慮到 `cp->h` 是直接從 `p->h` 複製且 `p->perfect` 為 NULL因此 `r` 會指派 `tcindex_lookup(cp, handle)`其值應與 相同`old_r`因此 `old_r && old_r != r` 條件在此情況下為假核心會忽略使用 tcindex_filter_result_init() 清除舊篩選結果的過程。因此只有當從 `p->perfect` 擷取 `old_r` 時核心才會使用 tcindex_filter_result_init() 清除舊的篩選結果進而觸發上述記憶體洩漏。考慮到已經存在 tc_filter_wq 工作佇列可以損毀舊的 tcindex_d ---truncated--- (CVE-2022-50396)

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

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

  - cryptoseqiv - 正確處理 EBUSY因為 seqiv 只會處理 EINPROGERSS 的特殊傳回值這表示在所有其他情況下它會釋放與要求相關的資料。不過由於 seqiv 的呼叫者可能會指定 MAY_BACKLOG因此我們也必須期待 EBUSY並以相同方式處理。
    否則積存的要求將會觸發釋放後使用。 (CVE-2023-53373)

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

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

  - net/mlx5exsk修正一般 rq 重新啟動時的損毀問題。在 XSK 通訊端關閉後重新啟動一般 rq 時可能會讀取到最終損毀 rq 的過時 cqes。這會導致一般 rq 不會再收到任何流量且會在下次關閉或停用 rq 時造成當機。Kal Cuttler Conely 將此問題報告為當 xdpsock 範例程式停止 (終止) 並在流量執行時依序重新啟動時版本路徑發生損毀。此修補程式會在 rq 排清期間排清所有 cqes。cqe 排清是在 rq 的重設狀態下完成的。 mlx5e_rq_to_ready 程式碼已移至排清函式以允許此情況。 (CVE-2023-53394)

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

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

  - 在某些情況下當 DNSdist 設定為使用 nghttp2 程式庫來處理 over HTTPS 查詢的傳入 DNS 時攻擊者可能藉由特製 DoH 交換來觸發無限制的 I/O 讀取迴圈進而造成拒絕服務未預期的 CPU 資源消耗。 (CVE-2025-30187)

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

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

  - WebRTC 中存在釋放後使用弱點。由 sherkito 於 2025 年 8 月 23 日報告。(CVE-2025-10501)

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

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

  - PM: EM修正使用 debugfs_lookup() 的記憶體洩漏。呼叫 debugfs_lookup() 時結果必須有呼叫 dput() 否則記憶體會隨著時間推移而洩漏。為使事情變得更簡單只要呼叫 debugfs_lookup_and_remove() 而不是它會立即處理所有邏輯。 (CVE-2023-53411)

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

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

  - md修正 mempool_free 中的一個損毀問題執行 lvm 測試 shell/lvchange-rebuild-raid.sh 時mempool_free 中存在一個損毀問題。當機的原因如下* super_written 呼叫 atomic_dec_and_test(&mddev->pending_writes) 和 wake_up(&mddev->sb_wait)。然後它會呼叫 rdev_dec_pending(rdev, mddev) 和 bio_put(bio)。 * 因此在 sb_wait 上等待且被喚醒的處理程序會與 bio_put(bio) 爭用。 * 如果處理程序贏得爭用則會在執行 bio_put(bio) 前呼叫 bioset_exit。 * bio_put(bio) 嘗試將 bio 釋放到已損毀的 bio 集中導致 mempool_free 損毀。我們將 bio_put 移至 atomic_dec_and_test 之前以修正此錯誤。我們也會依照 Neil Brown 的建議將 rdev_dec_pending 移至 atomic_dec_and_test 之前。md_end_flush 函式有一個類似的錯誤 - 我們必須先呼叫 bio_put 才能遞減進行中 bio 的數量。錯誤核心 NULL 指標解除參照位址0000000000000000 #PF核心模式中的監督寫入權限 #PFerror_code(0x0002)
    - 不存在的頁面 PGD 11557f0067 P4D 11557f0067 PUD 0 Oops0002 [#1] PREEMPT SMP CPU0 PID73 Comm
    kworker/0:1 未受污染的 6.1.0-rc3 #5 硬體名稱QEMU Standard PC (i440FX + PIIX, 1996)BIOS 1.14.0-2 2014 年 4 月 1 日 工作佇列kdelayd flush_expired_bios [dm_delay] RIP0010:mempool_free+0x47/ 0x80 程式碼48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 08 [] 89 4b 08 d 89 4b 08 <48> 89 2 e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00 RSP
    0018:ffff88910036bda8 EFLAGS: 00010093 RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8 RBP: ffff8891447ba240 R08:
     R090000000000012908  : 00000000003d0900 R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000 R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05 FS: 0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0 Call Trace: <TASK> clone_endio+0xf4/0x1c0 [dm_mod] clone_endio+0xf4/0x1c0 [dm_mod] __submit_bio+0x76/0x120 submit_bio_noacct_nocheck+0xb6/0x2a0 flush_expired_bios+0x28/0x2f [dm_delay] process_one_work+0x1b4/ 0x300 worker_thread+0x45/0x3e0 rescuer_thread+0x380/0x380 kthread+0xc2/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Modules linked in: brd dm_delay dm_raid dm_mod af_packet uvesafb cfbfillrect cfbimgblt cn cfbcopyarea fb font fbdev tun autofs4 binfmt_misc configfs ipv6 virtio_rng virtio_balloon rng_core virtio_net pcspkr net_failover failover qemu_fw_cfg button mousedev raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 md_mod sd_mod t10_pi crc64_rocksoft crc64 virtio_scsi scsi_mod evdev psmouse bsg scsi_common [上次卸載brdCVE-2022-50381CR20000000000000000 ---[ 結束追踪 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

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

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

  - 已解決 Linux 核心中的下列弱點：padata: Always leave BHs disabled when running ->parallel() A deadlock can happen when an overloaded system runs ->parallel() in the context of the current task: padata_do_parallel ->parallel() pcrypt_aead_enc/dec padata_do_serial spin_lock(&reorder->lock) // BHs still enabled <interrupt> ... __do_softirq ... padata_do_serial spin_lock(&reorder->lock) It's a bug for BHs to be on in _do_serial as Steffen points out, so ensure they're off in the current task case like they are in padata_parallel_worker to avoid this situation.
    (CVE-2022-50382)

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

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

  - net/mlx5e修正 mlx5e_fs_tt_redirect_any_create 中的記憶體洩漏。fs->any 指標指向的記憶體並未在 mlx5e_fs_tt_redirect_any_create 的錯誤路徑中釋放進而導致記憶體洩漏。透過釋放錯誤路徑中的記憶體來修正 藉此使錯誤路徑與 mlx5e_fs_tt_redirect_any_destroy() 相同。 (CVE-2023-53371)

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

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

  - 已解決 Linux 核心中的下列弱點：drm/i915/dpt: Treat the DPT BO as a framebuffer Currently i915_gem_object_is_framebuffer() doesn't treat the BO containing the framebuffer's DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I'm still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a) (CVE-2023-53378)

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

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

  - ANGLE 中的堆積緩衝區溢位弱點。由 Google Big Sleep 於 2025 年 8 月 12 日報告。(CVE-2025-10502)

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

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

  - 在 140.0.7339.185 之前的 Google Chrome 內，Dawn 中存在釋放後使用，遠端攻擊者可能利用此問題，透過建構的 HTML 頁面利用堆積損毀。(Chromium 安全性嚴重性 : 高) (CVE-2025-10500)

  - Dawn 中的釋放後使用弱點。由 Giunash (Gyujeong Jin) 於 2025 年 8 月 3 日報告。(CVE-2025-10500)

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

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

  - 已解決 Linux 核心中的下列弱點：NFSD: fix leaked reference count of nfsd4_ssc_umount_item The reference count of nfsd4_ssc_umount_item is not decremented on error conditions.
    This prevents the laundromat from unmounting the vfsmount of the source file. This patch decrements the reference count of nfsd4_ssc_umount_item on error. (CVE-2023-53381)

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

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

  - scsimpi3mr使用位元數管理點陣圖大小 若要配置點陣圖mpi3mr 驅動程式會使用位元組作為單位計算點陣圖大小。不過點陣圖協助程式函式會假設點陣圖是以不帶正負號的 long 為單位進行配置。此間隔會造成記憶體存取超出點陣圖大小並導致錯誤
    KASAN平台超出邊界。韌體下載至 eHBA-9600 時出現此錯誤。呼叫追踪指出從 mpi3mr_send_event_ack() 針對 miroc->evtack_cmds_bitmap 呼叫的 find_first_zero_bit() 發生超出邊界存取問題。若要修正此錯誤請勿使用位元組來管理點陣圖大小。請改用位元數並呼叫將位元數視為引數的點陣圖協助程式函式。針對記憶體配置呼叫 bitmap_zalloc()而非 kzalloc() 與 krealloc()。針對記憶體釋放呼叫 bitmap_free() 而非 kfree()。如需清除零請呼叫 bitmap_clear() 而非 memset()。移除結構 scmd_priv 中不再需要的三個點陣圖位元組大小欄位。將欄位 dev_handle_bitmap_sz 取代為 dev_handle_bitmap_bits可保留整個調整大小的 removepend_bitmap 位元數。 (CVE-2023-53376)

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

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

  - ACPICA將 AML_NO_OPERAND_RESOLVE 旗標新增至計時器 ACPICA 提交 90310989a0790032f5a0140741ff09b545af4bc5 根據 ACPI 規格 19.6.134不需要為 ASL 計時器指令傳送任何引數。為處理所有引數AML_NO_OPERAND_RESOLVE 旗標已新增至 ASL 計時器指令 opcode。ACPI 解譯器解譯 ASL 計時器指令時會發生錯誤。將 AML_NO_OPERAND_RESOLVE 旗標新增至 ASL 計時器指令 opcode 後未觀察到 問題。
    ================================================== =========== UBSANacpica/dswexec.c:401:12 索引 -1 中的 array-index-out-of-bounds 超出 'union acpi_operand_object *[9]' 類型 CPU37 的範圍 PID
    1678 Comm: cat 未受污染 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW 名稱NVIDIA BIOS v1.1.1-d7acbfc-dirty 2022 年 12 月 19 日 呼叫追踪dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50
    __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter] (CVE-2023-53395)

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

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

  - 已解決 Linux 核心中的下列弱點：HID: intel-ish-hid: Fix kernel panic during warm reset During warm reset device->fw_client is set to NULL. If a bus driver is registered after this NULL setting and before new firmware clients are enumerated by ISHTP, kernel panic will result in the function ishtp_cl_bus_match(). This is because of reference to device->fw_client->props.protocol_name. ISH firmware after getting successfully loaded, sends a warm reset notification to remove all clients from the bus and sets device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel module drivers were loaded right after any of the first ISHTP device was registered, regardless of whether it was a matched or an unmatched device. This resulted in all drivers getting registered much before the warm reset notification from ISH. Starting kernel v5.16, this issue got exposed after the change was introduced to load only bus drivers for the respective matching devices. In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are registered after the warm reset device fw_client NULL setting. cros_ec_ishtp driver_register() triggers the callback to ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel panic in guid_equal() when dereferencing fw_client NULL pointer to get protocol_name.
    (CVE-2023-53392)

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

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

  - 已解決 Linux 核心中的下列弱點：Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early Not calling hci_(dis)connect_cfm before deleting conn referred to by a socket generally results to use-after-free. When cleaning up SCO connections when the parent ACL is deleted too early, use hci_conn_failed to do the connection cleanup properly. We also need to clean up ISO connections in a similar situation when connecting has started but LE Create CIS is not yet sent, so do it too here. (CVE-2023-53374)

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

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

  - mediaatomisp防止 sh_css_set_black_frame() 中的整數溢位。高度和寬度值來自使用者因此高度 * 寬度乘法可能溢位。 (CVE-2022-50399)

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

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

  - ksmbd修正 smb2_get_info_filesystem() 中的 NULL 指標解除參照。如果共用為 則 share->path 為 NULL會造成 NULL 指標解除參照問題。 (CVE-2023-53399)

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

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

  - tpmtpm_crb新增遺漏的 acpi_put_table() 以修正記憶體洩漏。在 crb_acpi_add() 中我們取得 TPM2 表格來擷取如啟動方法之類的資訊然後將其指派給 priv 資料因此在應該釋放 init 時呼叫 acpi_put_table() 來修正記憶體洩漏。 (CVE-2022-50389)

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

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

  - mediamediatekvcodec當lat 解碼錯誤時無法將 dst 緩衝區設定為完成核心執行緒將呼叫 v4l2_m2m_buf_done為 lat 架構將 dst 緩衝區設定為完成。如果在 lat 解碼錯誤時lat 呼叫 v4l2_m2m_buf_done_and_job_finish 以釋放 dst 緩衝區核心執行緒會存取核心 NULL 指標解除參照然後當機。 (CVE-2022-50383)

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

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

  - NFS修正 nfs_d_automount() 中的 Oops 從 NFSv4 轉介掛載時path->dentry 可能會變成負的 dentry因此請改為從 dentry 本身衍生結構 nfs_server。 (CVE-2022-50385)

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

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

  - modpost修正 is_executable_section() 中的差一問題。 > 比較應該 >= 以防止超出邊界陣列存取。 (CVE-2023-53397)

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

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

  - drm/amdgpu修正 mes 自我測試中的記憶體洩漏。與 mes 佇列相關的隔離必須在 amdgpu_ring_fini 執行期間釋放。 (CVE-2023-53370)

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

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

  - 完整性修正 keyring 配置錯誤路徑中的記憶體洩漏。金鑰限制是在 Integration_init_keyring() 中配置。不過如果 keyring 配置失敗則不會予以釋放進而造成記憶體洩漏。
    (CVE-2022-50395)

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

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

  - drm/介子重新排序驅動程式 deinit 序列以修正釋放後使用錯誤 卸載驅動程式會觸發下列 KASAN 警告[ +0.006275] =================== ========================================== [+0.000029] 錯誤KASAN __list_del_entry_valid+0xe0/0x1a0 中的釋放後使用 [ +0.000026] 工作 rmmod/2695 在 addr ffff000020c395e0 讀取大小為 8 的錯誤 [ +0.000019] CPU5 PID2695 Commmod 污染的 GCO 5.19.0- rc6-lrmbkasan+ #1 [ +0.000013] 硬體名稱Hardkernel ODROID-N2Plus (DT) [ +0.000008] 呼叫追踪 [ +0.000007] dump_backtrace+0x1ec/0x280 [ +0.000013] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000008]
    __asan_report_load8_noabort+0x3c/0x50 [ +0.000010] __list_del_entry_valid+0xe0/0x1a0 [ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm] [ +0.000172] drm_bridge_detach+0x94/0x260 [drm] [ +0.000145] drm_encoder_cleanup+0x4/x 0x290 [drm] [ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm] [ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm] [ +0.000144] drm_managed_release+0x170/0x414 [drm] [+0.000142] drm_dev_put。 part.0+0xc0/0x124 [drm] [ +0.000143] drm_dev_put+0x20/0x30 [drm] [ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm] [ +0.000028] take_down_aggregate_device+0xb0/0x160 [ +0.000016] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000015] platform_remove+0x64/0xb0 [ +0.000009] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000009] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [ meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000011]
    __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000018] 由工作 0 分配 [ +0.000007] (堆疊不可用) [ +0.000011] 由工作 2695 釋放[ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000009]____kasan_slab_free+0x128/0x1d4 [ +0.000008]
    __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000011] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [+0.000008] component_unbind+0x128/0x1e0 [ +0.000010] component_unbind_all+0x1b8/0x264 [ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm] [ +0.000025] take_down_aggregate_device+0xb0/0x160 [ +0.000009] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000012] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/ 0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000011] __doe_modulesys_delet +0x288/0x400 [ +0.000010]
    __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] 錯誤位址屬於 ffff000020c39000 的物件 ---truncated--- (CVE-2022-50378)

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

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

  - irqchip/gicv3NVIDIA 錯字勘誤表 T241-FABRIC-4 的因應措施 T241 平台受到 T241-FABRIC-4 錯字勘誤表的影響當同時從不同來源收到多個交易時會造成 GIC 出現未預期的行為。此硬體問題會影響使用兩個以上互連 T241 晶片的 NVIDIA 伺服器平台。每個晶片都支援 320 {E}SPI。當來自不同 GIC 的多個封包在目標晶片上未正確交錯時會發生此問題。以下錯字勘誤表文字確切說明了造成多個傳輸封包交錯影響的原因以及 GIC 狀態損毀的原因。GIC 狀態損毀可導致一系列問題包括核心錯誤和未預期的行為。 >來自錯字勘誤表文字在某些情況下具有多個傳輸的通訊端間 AXI4 資料流封包在呈現給 ARM 泛型中斷控制器時可能會遭到光纖網路交錯處理。GIC 預期封包的所有傳輸都在沒有任何交錯的情況下傳送。下列 GICv3 命令可能導致在通訊端間 AXI4 Stream 介面上發生多個傳輸封包- 從 GICD_I* 和 GICD_N* 登錄讀取 - 將登錄寫入 GICD_IROUTERn* 以外的 64 位元 GICD 暫存器 - ITS 命令 MOVALL GICv4+ 中的多個命令利用多個傳輸封包，包括 VMOVP、VMOVI、VMAPP 和 64 位元暫存器存取。此問題會影響具有 2 個以上通訊端的系統組態其需要透過不同通訊端上 GIC 執行個體之間的通訊端間 AXI4 Stream 介面傳送多重傳輸封包。無法支援 GICv4。僅能透過因應措施支援 GICv3 SW 模型。
    單和雙通訊端組態不受此問題影響且支援 GICv3 和 GICv4。寫入 GICD_In{E} 暫存器之晶片別名區域 (GICD_ICENABLERn 除外) 的效果與寫入至全域發行者的效果相同。SPI 中斷停用路徑不受此錯字勘誤表影響。若要修正此問題請實作因應措施確保將 GICD_In{E} 暫存器的讀取存取導向擁有 SPI 的晶片並停用 GICv4.x 功能。為簡化程式碼變更gic_configure_irq() 函式會對 GICD_ICFGR 的讀取和寫入作業使用相同的別名區域。
    (CVE-2023-53383)

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

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

  - 已解決 Linux 核心中的下列弱點：net: hinic: fix the issue of CMDQ memory leaks When hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is not released correctly. Fix it. (CVE-2022-50387)

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

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

  - 已解決 Linux 核心中的下列弱點：tracing: Free error logs of tracing instances When a tracing instance is removed, the error messages that hold errors that occurred in the instance needs to be freed. The following reports a memory leak: # cd /sys/kernel/tracing # mkdir instances/foo # echo 'hist:keys=x' > instances/foo/events/sched/sched_switch/trigger # cat instances/foo/error_log [ 117.404795] hist:sched:sched_switch: error: Couldn't find field Command:
    hist:keys=x ^ # rmdir instances/foo Then check for memory leaks: # echo scan > /sys/kernel/debug/kmemleak # cat /sys/kernel/debug/kmemleak unreferenced object 0xffff88810d8ec700 (size 192): comm bash, pid 869, jiffies 4294950577 (age 215.752s) hex dump (first 32 bytes): 60 dd 68 61 81 88 ff ff 60 dd 68 61 81 88 ff ff `.ha....`.ha.... a0 30 8c 83 ff ff ff ff 26 00 0a 00 00 00 00 00 .0......&....... backtrace:
    [<00000000dae26536>] kmalloc_trace+0x2a/0xa0 [<00000000b2938940>] tracing_log_err+0x277/0x2e0 [<000000004a0e1b07>] parse_atom+0x966/0xb40 [<0000000023b24337>] parse_expr+0x5f3/0xdb0 [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560 [<00000000293a9645>] trigger_process_regex+0x135/0x1a0 [<000000005c22b4f2>] event_trigger_write+0x87/0xf0 [<000000002cadc509>] vfs_write+0x162/0x670 [<0000000059c3b9be>] ksys_write+0xca/0x170 [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0 [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc unreferenced object 0xffff888170c35a00 (size 32): comm bash, pid 869, jiffies 4294950577 (age 215.752s) hex dump (first 32 bytes): 0a 20 20 43 6f 6d 6d 61 6e 64 3a 20 68 69 73 74 . Command: hist 3a 6b 65 79 73 3d 78 0a 00 00 00 00 00 00 00 00 :keys=x......... backtrace: [<000000006a747de5>] __kmalloc+0x4d/0x160 [<000000000039df5f>] tracing_log_err+0x29b/0x2e0 [<000000004a0e1b07>] parse_atom+0x966/0xb40 [<0000000023b24337>] parse_expr+0x5f3/0xdb0 [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560 [<00000000293a9645>] trigger_process_regex+0x135/0x1a0 [<000000005c22b4f2>] event_trigger_write+0x87/0xf0 [<000000002cadc509>] vfs_write+0x162/0x670 [<0000000059c3b9be>] ksys_write+0xca/0x170 [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0 [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc The problem is that the error log needs to be freed when the instance is removed. (CVE-2023-53375)

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

ID	名稱	嚴重性
265595	Linux Distros 未修補的弱點：CVE-2025-59518	high
265594	Linux Distros 未修補的弱點：CVE-2022-50365	medium
265593	Linux Distros 未修補的弱點：CVE-2023-53366	medium
265592	Linux Distros 未修補的弱點：CVE-2022-50343	medium
265591	Linux Distros 未修補的弱點：CVE-2022-50358	medium
265590	Linux Distros 未修補的弱點：CVE-2022-50357	medium
265589	Linux Distros 未修補的弱點：CVE-2023-53314	medium
265588	Linux Distros 未修補的弱點：CVE-2023-53311	high
265587	Linux Distros 未修補的弱點：CVE-2023-53345	medium
265586	Linux Distros 未修補的弱點：CVE-2022-50354	medium
265585	Linux Distros 未修補的弱點：CVE-2023-53408	medium
265584	Linux Distros 未修補的弱點：CVE-2022-50392	medium
265583	Linux Distros 未修補的弱點：CVE-2023-53369	medium
265582	Linux Distros 未修補的弱點：CVE-2022-50388	medium
265581	Linux Distros 未修補的弱點：CVE-2023-53391	medium
265580	Linux Distros 未修補的弱點：CVE-2023-53380	medium
265579	Linux Distros 未修補的弱點：CVE-2023-53410	medium
265578	Linux Distros 未修補的弱點：CVE-2023-53402	medium
265577	Linux Distros 未修補的弱點：CVE-2023-53387	medium
265576	Linux Distros 未修補的弱點：CVE-2022-50393	medium
265575	Linux Distros 未修補的弱點：CVE-2022-50394	high
265574	Linux Distros 未修補的弱點：CVE-2022-50396	medium
265573	Linux Distros 未修補的弱點：CVE-2023-53373	high
265572	Linux Distros 未修補的弱點：CVE-2023-53394	medium
265571	Linux Distros 未修補的弱點：CVE-2025-30187	low
265570	Linux Distros 未修補的弱點：CVE-2025-10501	high
265569	Linux Distros 未修補的弱點：CVE-2023-53411	medium
265568	Linux Distros 未修補的弱點：CVE-2022-50381	medium
265567	Linux Distros 未修補的弱點：CVE-2022-50382	medium
265566	Linux Distros 未修補的弱點：CVE-2023-53371	medium
265565	Linux Distros 未修補的弱點：CVE-2023-53378	medium
265564	Linux Distros 未修補的弱點：CVE-2025-10502	high
265561	Linux Distros 未修補的弱點：CVE-2025-10500	high
265560	Linux Distros 未修補的弱點：CVE-2023-53381	medium
265559	Linux Distros 未修補的弱點：CVE-2023-53376	high
265558	Linux Distros 未修補的弱點：CVE-2023-53395	high
265557	Linux Distros 未修補的弱點：CVE-2023-53392	high
265556	Linux Distros 未修補的弱點：CVE-2023-53374	high
265555	Linux Distros 未修補的弱點：CVE-2022-50399	high
265554	Linux Distros 未修補的弱點：CVE-2023-53399	medium
265553	Linux Distros 未修補的弱點：CVE-2022-50389	medium
265552	Linux Distros 未修補的弱點：CVE-2022-50383	medium
265551	Linux Distros 未修補的弱點：CVE-2022-50385	medium
265550	Linux Distros 未修補的弱點：CVE-2023-53397	medium
265549	Linux Distros 未修補的弱點：CVE-2023-53370	medium
265548	Linux Distros 未修補的弱點：CVE-2022-50395	medium
265547	Linux Distros 未修補的弱點：CVE-2022-50378	high
265546	Linux Distros 未修補的弱點：CVE-2023-53383	medium
265545	Linux Distros 未修補的弱點：CVE-2022-50387	medium
265544	Linux Distros 未修補的弱點：CVE-2023-53375	medium

偵測

Nessus 的 Misc. 系列

high

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

medium

high

medium

low

high

medium

medium

medium

medium

medium

high

high

medium

high

high

high

high

high

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

medium