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

  - MongoDB BI 連接器 ODBC 驅動程式會將浮點直欄值轉換成文字，而不檢查結果是否適合目的地緩衝區。當應用程式將足夠大的浮點值讀取為文字時，驅動程式可能會寫入超出該緩衝區結尾的文字，並損毀相鄰記憶體。可將資料儲存在透過 BI 連接器讀取的集合中的使用者可以使用此功能來損毀執行讀取的應用程式。（CVE-2026-18888）

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

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

  - 已解決 Linux 核心中的下列弱點：KVM: SEV: Allocate full pages for {DE,EN}CRYPT ops on SNP-enabled hosts When {de,en}crypting memory of an SEV or SEV-ES guest on an SNP-enabled host via a temporary buffer, allocate a full 4KiB page for the buffer to ensure the page containing the buffer is wholly owned by KVM, i.e. won't be concurrently allocated and accessed by other kernel code while KVM is using the buffer to {de,en}crypt memory. On SNP-enabled platforms, when sending SEV/SEV-ES commands that trigger firmware writes to memory, the to-be-written page(s) must be (temporarily) assigned to Firmware (as required by the SNP architecture, to guard against using such commands as gadgets to attack SNP guests). See snp_map_cmd_buf_desc() and friends. Unfortunately, transferring ownership of a page to Firmware makes the page inaccessible to software, and thus writes generate RMP #PF violations. If KVM uses a sub-page allocation for its temporary buffer, some other actor in the kernel can allocate and use the other portions of the page, and thus trigger unexpected (and seemingly spurious) RMP #PF violations due to software attempting to access a Firmware-owned page. BUG:
    unable to handle page fault for address: ffff906ae30f0300 #PF: supervisor write access in kernel mode #PF:
    error_code(0x80000003) - RMP violation PGD 6b1b80d067 P4D 6b1b80d067 PUD 100231e2063 PMD 10055a88063 PTE 80000100630f0163 SEV-SNP: PFN 0x100630f0 unassigned, dumping non-zero entries in 2M PFN region:
    [0x10063000 - 0x10063200] Oops: Oops: 0003 [#1] SMP CPU: 70 UID: 0 PID: 10658 Comm: svw_WaiterThrea Tainted: G U W O 7.1.0-smp--c22293789940-seanjc-next #1 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP:
    0010:memset+0xf/0x20 Call Trace: <TASK> __kvmalloc_node_noprof+0x2a4/0x710 do_getxattr+0x4e/0x130 path_getxattrat+0x125/0x1b0 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP:
    0033:0x7f3a22cb6daa </TASK> Modules linked in: kvm_amd kvm irqbypass vfat fat ccp k10temp sha3 libsha3 i2c_piix4 gq(O) cdc_acm xhci_pci xhci_hcd gsmi: Log Shutdown Reason 0x03 CR2: ffff906ae30f0300 ---[ end trace 0000000000000000 ]--- RIP: 0010:memset+0xf/0x20 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x39e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) gsmi:
    Log Shutdown Reason 0x02 (CVE-2026-80853)

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

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

  - nvmet：修正 nvmet_execute_identify_nslist（） 中的 NULL 指標解除參照 當主機以 CNS 07h （特定 I/O 命令集的作用中命名空間識別碼清單） 發出識別命令時，會呼叫具有match_css集的 nvmet_execute_identify_nslist（）。命令集篩選器解除參照 req->ns，但此處理常式從不呼叫 nvmet_req_find_ns（），因此 req->ns 一律為 NULL （nvmet_req_init（） 將其重設為 NULL）。一旦存在 NSID 大於要求值的已啟用命名空間，req->ns->csi 就會解除參照 NULL 指標並失敗。除了損毀之外，比較在邏輯上也是錯誤的：若要依命令集篩選清單，它必須測試正在反覆運算的命名空間的命令集，而不是單一固定值。使用迴圈變數 ns->csi。（CVE-2026-80813）

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

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

  - alpha/PCI：將 security_locked_down（） 檢查新增到 pci_mmap_resource（） 目前，Alpha 的 pci_mmap_resource（） 不會在允許使用者空間 mmap PCI BAR 之前檢查 security_locked_down（LOCKDOWN_PCI_ACCESS）。通用版本自提交 eb627e17727e （PCI：鎖定核心時鎖定 BAR 存取） 以來一直進行此檢查，以防止核心鎖定時的 DMA 攻擊。將相同的檢查新增至 Alpha 的 pci_mmap_resource（）。（CVE-2026-80867）

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

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

  - iommu/tegra241-cmdqv：修正在 arm_smmu_init_queues（） 配置 smmu->cmdq.q.base 之前，CMD_SYNC拆卸時的釋放後使用 arm_smmu_impl_remove（） 在 arm_smmu_impl_probe（） 中註冊為 devres 動作的問題。在 devres 展開時，無論是失敗的探查還是解除綁定，都會先釋放佇列，然後 arm_smmu_impl_remove（） 執行 tegra241_cmdqv_remove_vintf（），其 VINTF deinit 會在釋放的記憶體上發出CMD_SYNC。
    在測試期間觀察到 QEMU 駭客攻擊，導致 VCMDQ 無法啟用，因此 impl 重設失敗，並且探查中止到 devres 展開：平台 NVDA200C：00：tegra241_cmdqv：VINTF0：VCMDQ0/LVCMDQ0：無法啟用，STATUS=0x00000000 平台 NVDA200C：00：tegra241_cmdqv：VINTF0：VCMDQ0/LVCMDQ0：GERRORN=0x0、GERROR=0x4、CONS=0x0 平台 NVDA200C：00： tegra241_cmdqv： VINTF0： VCMDQ0/LVCMDQ0：偵測到未清除的錯誤，正在重設 arm-smmu-v3 arm-smmu-v3.0.auto：無法重設 impl arm-smmu-v3 arm-smmu-v3.0.auto：
    使用驅動程式 arm-smmu-v3 的探查失敗，並出現錯誤 -110 無法處理虛擬位址 ffff8000891e0098 上的核心分頁要求 ... 內部錯誤：哎呀：0000000096000047 [#1] SMP ... 呼叫追蹤：
    arm_smmu_cmdq_issue_cmdlist+0x320/0x6fc （P） tegra241_vcmdq_hw_deinit+0x98/0x168 tegra241_vintf_hw_deinit+0x5c/0x1b0 tegra241_cmdqv_remove_vintf+0x34/0xec tegra241_cmdqv_remove+0x40/0x9c arm_smmu_impl_remove+0x20/0x30 devm_action_release+0x14/0x20 devres_release_all+0xa8/0x110 device_unbind_cleanup+0x18/0x84 really_probe+0x1f0/0x29c 從 tegra241_cmdqv_remove_vintf（） 刪除 VINTF deinit，以便展開不再接觸釋放的佇列。改為提前靜止 VINTF。新增一個 device_disable（） impl 操作，並在 CMDQ 仍啟動時從 arm_smmu_disable_action（） 執行它。這會處理即時解除綁定。失敗的重設已處理，因為 tegra241_vintf_hw_init（） 會在自己的錯誤路徑上 deinit VINTF。tegra241_cmdqv_remove_vintf（） 也被 iommufd viommu destroy 路徑使用，因此也在那裡靜止。（CVE-2026-80818）

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

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

  - 在 valkey-io valkey 9.0.5中發現了一個弱點，直到 /9.1.1。這會影響檔案 src/kvstore.c 的函式 kvstoreGetHash表。這種對引數 didx 的操作會導致越界讀取。攻擊者可從遠端發動攻擊。攻擊被認為具有高度複雜性。這表明可利用性是困難的。該漏洞已向公眾開放，可用於攻擊。修補程式名稱：4691888e7fab3df128f0bde5750c9fde2ae552fa。若要修正此問題，建議部署修補程式。利用需要叢集模式以及啟動時攻擊者控制的 dump.rdb （資料目錄寫入存取權、複製摘要或儲存的特製 RDB） - 攻擊者在啟動時的位置 DoS，而不是網路預先驗證。該問題報告已關閉，指出為了內存安全，值得修復，但我認為它不符合我們的安全披露標準。（CVE-2026-86227）

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

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

  - nvmet： pci-epf：修正 nvmet_pci_epf_exec_iod_work（） 中的釋放後使用 nvmet_pci_epf_exec_iod_work（） 會以 req->execute（） 提交 I/O 命令，然後等待命令完成並將資料傳回主機。對於不將資料從裝置傳輸到主機的命令，不需要此等待。
    為了決定是否需要等待，它會在呼叫 req->execute（） 之後讀取 iod->data_len 和 iod->dma_dir。但是，一旦呼叫 req->execute（），該命令可能會在另一個 CPU 上非同步完成。對於不需要裝置到主機資料傳輸的命令，nvmet_pci_epf_queue_response（） 會直接呼叫 nvmet_pci_epf_complete_iod（），這可以在 iod 讀取 iod->data_len 和 iod->dma_dir 之前釋放 iod，從而導致 KFENCE 釋放後使用： 錯誤：KFENCE：nvmet_pci_epf_exec_iod_work+0x288/0x798 中的釋放後使用讀取 [nvmet_pci_epf] 0x00000000fdfa6d03 處的釋放後使用讀取 （在 kfence-#63）：nvmet_pci_epf_exec_iod_work+0x288/0x798 [nvmet_pci_epf] process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20 kfence-#63：
    0x00000000e3de0e71-0x00000000c938ad62，size=712， cache=kmalloc-1k 由 CPU 0 上的任務 10 在 73.995480s （0.005122s 秒前） 分配）： mempool_kmalloc+0x1c/0x28 mempool_alloc_noprof+0x40/0x9c nvmet_pci_epf_poll_sqs_work+0xd4/0x344 [nvmet_pci_epf] process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20 在 CPU 3 上的任務 131 在 73.995521 秒（0.008385 秒前）釋放： mempool_kfree+0x10/0x20 mempool_free+0x44/0x64 nvmet_pci_epf_free_iod+0x88/0x98 [nvmet_pci_epf] nvmet_pci_epf_cq_work+0xfc/0x280 [nvmet_pci_epf] process_one_work+0x15c/0x4f0 worker_thread+0x18c/0x30c kthread+0x130/0x140 ret_from_fork+0x10/0x20 在呼叫 req->execute（） 之前參考 iod->data_len 和 iod->dma_dir 來修正此問題。其餘的 iod 存取 （例如 iod->status） 只能在裝置到主機的讀取路徑上存取。在這種情況下，nvmet_pci_epf_queue_response（） 會發出 iod->done 訊號，而不是釋放 iod，因此 iod 保持有效。
    (CVE-2026-80787)

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

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

  - HID： rapoo：修正缺少的 hid_is_usb（） 檢查 to_usb_interface（） 只能在父系確實是 USB 的hid_device上使用;uhid 可以建立識別為在BUS_USB上但實際上沒有 USB 父項的裝置。修正在沒有 hid_is_usb（） 檢查的情況下使用 to_usb_interface（） 的問題。新增 hid_is_usb（） USB_HID相依性，就像其他 HID 驅動程式一樣;另一種方法是在 ！USB_HID組建。我已驗證，由於 ASAN 構建中的此錯誤，目前可以觸發核心 splat，並且此提交解決了該問題。（CVE-2026-80769）

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

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

  - netfs：在複製到快取附加失敗時清除PG_private_2 netfs_pgpriv2_copy_to_cache（） 會在 netfs_pgpriv2_copy_folio（） 將對開本附加到複製到快取滾動緩衝區之前用PG_private_2標示對開本。如果附加失敗，對開本不會排入快取回寫佇列，因此必須立即釋放PG_private_2狀態及其參照。（CVE-2026-80898）

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

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

  - IB/mlx5：正確支援隱含 ODP rereg_mr 由於隱含 ODP 組態中的所有子 mkey，我們無法變更父 mkey 的任何內容。相反，如果要求任何更改，則需要重建整個事情。如果使用者未指定轉換，則強制隱含值，然後透過邏輯落入 mlx5_ib_reg_user_mr（） 以配置全新的 MR。
    由於隱性兒童也在觸摸 mr->pd，這消除了另一個訪問是色情的案例。（CVE-2026-80880）

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

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

  - ASoC： SDCA： 使 UMP 訊息大小檢查更健全：如果訊息偏移大於緩衝區長度，則大小檢查將不正確通過。重構檢查，使其對無效大小更具穩健性。
    (CVE-2026-80900)

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

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

  - mshv：根據 irqfd 判斷提示路徑排序pt_vp_array發佈 mshv_partition_ioctl_create_vp（） 初始化 VP 結構 （配置、mutex_init、init_waitqueue_head、頁面映射），然後將指標發佈到 partition->pt_vp_array。數個 ISR 路徑以無鎖定方式讀取此陣列：攔截 ISR、兩個排程器 ISR 和 irqfd 快速路徑上的 mshv_try_assert_irq_fast（）。其中，只有 mshv_try_assert_irq_fast（） 可以在結構上爭用發布。它從 eventfd 喚醒程式執行，無需保留 pt_mutex，而且MSHV_IRQFD不需要目標lapic_apic_id （== vp_index） 在註冊時參照現有的 VP。因此，使用者可以註冊以尚未建立的 VP 為目標的 irqfd，然後針對相同索引同時觸發 mshv_try_assert_irq_fast（） 與 MSHV_CREATE_VP。在弱排序架構上，在 VP 結構的初始化儲存變得可見之前，閱讀器可以在 pt_vp_array 中觀察到非 NULL 指標，從而導致使用部分初始化的欄位 （例如
    vp_register_page）。其他 ISR 讀取器無法達到此競爭：Hypervisor 不會為從未被告知執行的 VP 產生攔截或排程器訊息，而且使用者只能在 MSHV_CREATE_VP 傳回的 VP fd 上呼叫 MSHV_RUN_VP，而 VP fd 會建構在發佈之後傳回。
    讓這些讀者作為普通負載。在 mshv_partition_ioctl_create_vp（） 中使用 smp_store_release（） 來發布指標，並將其與 mshv_try_assert_irq_fast（） 中的 smp_load_acquire（） 配對。在 x86 上，這些會編譯為 TSO 下的純存取;它們發出 ARM64 單指令獲取/釋放障礙，在此快速路徑上是可以接受的。破壞端路徑 （destroy_partition（） 清除 pt_vp_array kfree（vp） 之後的 [i] 到 NULL） 有一個單獨的排序和存留期問題，這超出了此處的範圍。（CVE-2026-80895）

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

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

  - MongoDB Server 的 Queryable Encryption 維護作業中的一個問題，可能允許具有一個加密集合權限的已驗證使用者，導致未經授權修改或銷毀屬於不同集合的資料。這是因為在某些內部中繼資料參照用於在其他命名空間上執行作業之前，未充分驗證這些參照。（CVE-2026-18712）

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

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

  - MongoDB Server 中的一個問題可能允許已驗證的使用者 （包括未指派權限的使用者） 透過提交特殊格式的彙總命令，導致伺服器處理程序意外終止。這可能會導致拒絕服務。（CVE-2026-18707）

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

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

  - bpf：將遺漏的 access_ok 呼叫新增至 copy_user_syms 正如 sashiko 所報告的，我們使用 __get_user，而沒有事先access_ok呼叫使用者空間指標。新增整個指標陣列的遺漏呼叫。另外，刪除錯誤路徑中的錯誤檢查，因為它不是必需的，而且我們可以直接從第一個kvmalloc_array失敗路徑返回 -ENOMEM。[1] https://lore.kernel.org/bpf/20260611115503.AC16D1F00893@smtp.kernel.org/ （CVE-2026-80865）

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

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

  - ASoC： SOF： sof-audio： 修正 sof_widget_setup_unlocked （） 中的錯誤路徑 如果在小組件設定期間tplg_ops->dai_config或widget_kcontrol_setup失敗，我們將加倍遞減小組件的use_count，因為 sof_widget_free_unlocked（） 會呼叫兩次，同樣地，core_put也會被叫用兩次。由於 use_count 和 core_put（） 是在 widget_free 函數中處理的，因此我們需要返回而不落入pipe_widget_free標籤。fixes 標籤被挑選到程式碼這部分周圍的最後一個更改，該更改足夠舊，可以反向移植。（CVE-2026-80911）

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

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

  - io_uring/rsrc：修正 io_vec_fill_bvec（） 中的作品集大小溢位 io_vec_fill_bvec（） 使用純 int 1 計算作品集大小：無符號長folio_size = 1 << imu->folio_shift;imu->folio_shift 是未簽名的 int，來自支援已註冊緩衝區的對開本的 folio_shift（），因此在 64 位元核心上它可以是 32 或更多。將 int 1 移位到那段距離是未定義的，並且在 x86 和 arm64 上，計數以 32 為模，因此移位 34 會產生 4 而不是 16G。此檔案中的每隔一次folio_shift班次都已使用 1UL。結果是線段估計值和填充迴圈不一致。io_estimate_bvec_size（） 使用實數移位調整 bvec 陣列的大小：max_segs += （iov[i].iov_len >> 移位） + 2;因此，16G 對開本上的 1M iovec 會收取 2 段費用，而 io_vec_fill_bvec（） 然後以 4 位元組folio_size區塊中遍歷相同的 iovec，並寫入 res_bvec[bvec_idx] 25 萬次，超過給定的陣列末尾。src_bvec每次反覆運算也會前進一次，因此 imu->bvec 會同時讀取其結尾。
    validate_fixed_range（） 只會檢查範圍是否在已註冊的緩衝區內，而不限制區段計數。到達它需要一個至少 32 位移的對開本，這意味著一個巨大的 hugetlb 頁面：
    arm64 上的 16G 和 64K 頁面，其中 CONT_PMD_SHIFT 是 34，hugetlb_add_hstate（CONT_PMD_SHIFT - PAGE_SHIFT） 註冊該大小，在 powerpc 上也是如此。x86_64最高為 1G，因此移位為 30，仍然適合 int 並且不受影響。使用 1UL，就像檔案的其餘部分一樣。（CVE-2026-80810）

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

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

  - futex/pi：拒絕 cross-mm 私有 futex 擁有者 私有 futex 金鑰會借用服務員的 mm，而不進行mm_users參照。儘管如此，attach_to_pi_owner（） 目前接受來自不同位址空間的所有者，並將私密金鑰複製到所有者的 PI 狀態中。當該所有者退出時，exit_pi_state_list（） 會使用已儲存的金鑰來尋找雜湊儲存桶，並取得服務員私有雜湊的參照。如果服務員 mm 的最後一個使用者同時退出，futex_hash_free（） 會釋放雜湊，而所有者仍使用其儲存桶和參照。透過在 attach_to_pi_owner（） 中驗證對於私有 futex，owner mm 和 waiter mm 是相同的，以防止這種情況發生。在保留所有者的 pi_lock 並在驗證 owner：：futex：：state 的情況下執行檢查，以針對並行 PI 狀態結束清除進行序列化。[ tglx：修改後的評論 ]（CVE-2026-80778）

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

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

  - afs： 修正 vllist 洩漏 如果新 vllist 是空清單 （nr_servers == 0），則修正 afs_update_cell（） 中新 vllist 的洩漏，在這種情況下，除非舊清單也是空的，否則不會取代舊清單。
    (CVE-2026-80877)

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

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

  - ocfs2：修正 ocfs2_read_blocks（） 中的緩衝區頭管理 在 ocfs2_read_blocks（） 中，調用方不應假設 'sb_getblk（）' 傳回的緩衝區頭是獨佔擁有的，因此 'put_bh（）' 總是b_count從 1 下降到 0。如果不是這樣，緩衝區頭將保持保留狀態，並且下次調用「sb_getblk（）」時可能會傳回不變 - 也就是說，即使之前驗證失敗，也會設定BH_Uptodate位元，從而允許將該緩衝區頭插入 OCFS2 中繼資料快取並將其提交到上層。為避免這種情況，應在 'validate（）' 回呼偵測到某些資料不一致後立即清除BH_Uptodate。（CVE-2026-80881）

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

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

  - ALSA：scarlett2：針對通知端點使用私人 URB scarlett2_init_notify（） 使用 mixer->urb，snd_usb_mixer_status_create（） 會配置給 UAC2 狀態中斷端點，而 mixer.c 會管理。
    在具有該端點的裝置上，已在使用的檢查會在狀態 URB 上觸發，並傳回 0 以表示成功，而不執行任何動作。不會提交任何通知 URB，而且 cmd_done 會保留為零，因為它會在該檢查之後初始化，而且沒有其他任何地方。scarlett2_usb_init（） 然後發出 SCARLETT2_USB_INIT_1，wait_for_completion_timeout（） 將當機新增至歸零的 wait.head。在 scarlett2_data 中使用單獨的 URB （就像對 FCP 所做的那樣），並在 scarlett2_init_private（） 中初始化cmd_done。mixer.c 也釋放了 snd_usb_mixer_free（） 中的 URB 並在 snd_usb_mixer_activate（） 中重新提交，因此 scarlett2 現在必須同時執行這兩項操作：新增從 private_free 和 private_suspend 呼叫的 scarlett2_cleanup_urb（），以及恢復後重新建立 URB 的private_resume回呼。從該處到達 scarlett2_init_notify（），而 scarlett2_notify（） 中的 URB 終止路徑會完成cmd_done，留下過時的計數，可在裝置 ACK 之前滿足下一個命令的等候時間。使用 reinit_completion（） 清除它。如果傳輸緩衝區配置失敗，也請釋放 URB，如果 usb_submit_urb（） 失敗，兩者都會釋放。將 scarlett2_init_notify（） 移至 scarlett2_cleanup_urb（） 旁邊，以便 scarlett2_init_private（） 無需前向宣告即可參照它。（CVE-2026-80815）

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

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

  - 在 FreeIPA 中發現一個缺陷。自我管理的 OTP 權杖 ACI 不需要驗證，也不會限制哪些屬性可以與權杖項目一起新增。未經驗證的 LDAP 用戶端可以利用這一點，結合基礎目錄伺服器 ACI 評估中的相關缺陷 （單獨追蹤），建立任意攻擊者控制的 Kerberos 主體，並將其新增至管理員群組。這可讓遠端未經驗證的攻擊者取得真正的 FreeIPA 管理員群組成員資格，並針對目錄以及在啟用 SID 的部署上執行其他 IdM 服務執行管理作業。（CVE-2026-76578）

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

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

  - ntopng 之前 6.7.260717 無法檢查集區大量刪除端點中的使用者權限，允許經過驗證的非管理員刪除所有主機集區和成員繫結。攻擊者可向刪除集區端點發出 POST 要求，以不可逆轉的方式銷毀每個主機集區，移除可能略過安全性原則的流量原則繫結和可見性限制。（CVE-2026-86091）

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

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

  - arm64：dts：Renesas：ironhide：描述內嵌 ECC 分離 DBSC5 DRAM 控制器使用內嵌 ECC 保護 DRAM 內容。內嵌 ECC 利用 DRAM 區域進行操作，這些區域位於 DRAM 位址範圍內，但不得存取或修改。將此硬體上 DBSC5 控制器使用的內嵌 ECC 分割區域描述為保留記憶體，不得存取。也包括不受 ECC 保護的 DRAM 區域，這些是 ECC 分割之前的 DRAM 部分。在 DRAM 使用率較高的情況下，除非正確保留內嵌 ECC 分離，否則 Linux 可能會使用並損毀 DBSC5 DRAM 控制器用於內嵌 ECC 的記憶體，從而導致系統變得不穩定。（CVE-2026-80874）

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

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

  - 已解決 Linux 核心中的下列弱點：ntfs: bound the attribute-list entry in ntfs_read_inode_mount() The $MFT attribute-list walk in ntfs_read_inode_mount() validates each entry only with (u8 *)al_entry + 6 > al_end and (u8 *)al_entry + le16_to_cpu(al_entry->length) > al_end, but then reads al_entry->lowest_vcn (an __le64 at offset 8) and al_entry->mft_reference (offset 16) -- fields beyond the 6 bytes proven in range. al_entry->length is attacker-controlled and only required non-zero, so a short entry (e.g. length 8) placed at the tail passes both checks while the lowest_vcn / mft_reference reads fall past al_end. al_end is ni->attr_list + attr_list_size (the on-disk size); the buffer is kvzalloc(round_up(attr_list_size, SECTOR_SIZE)), so the sector rounding usually absorbs the over-read -- but when attr_list_size is a multiple of SECTOR_SIZE there is no slack and a crafted $MFT attribute list produces an out-of-bounds read at mount time. Validate the entry with ntfs_attr_list_entry_is_valid() (added in patch 1/3) before dereferencing it, matching the bound the other attribute-list walks now use.
    The validator already requires the length to cover the fixed header, which makes the separate !al_entry->length check redundant, so drop it too. (CVE-2026-80869)

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

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

  - netfs：在迭代器準備失敗 netfs_prepare_read_iterator（） 批次處理 put_batch 中的預讀對開本時釋放預讀對開本，以便在準備 I/O 迭代器後可以刪除對開本參照。如果在批次處理先前的對開本後 rolling_buffer_load_from_ra（） 失敗，則函式會立即傳回，並保留這些參照。在傳回錯誤之前釋放批次。
    (CVE-2026-80897)

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

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

  - Bluetooth： MGMT：拒絕 255 以上的HCI_CMD_SYNC params_len mgmt_hci_cmd_sync（） 檢查訊息長度是否與params_len一致，但沒有設定上限。params_len 是__le16，而 HCI 命令標頭中的參數長度是 u8： struct hci_command_hdr { __le16 opcode; __u8 plen; } __packed;
    hci_cmd_sync_alloc（） 將一個分配給另一個：hdr->plen = plen;if （plen） skb_put_data（skb， param， plen）;
    因此，params_len 256 會使 plen 為 0，而所有 256 位元組仍會附加。然後交給駕駛員的框架沒有聲明任何參數並帶有其中的 256 個參數。在長度框架傳輸 （例如 H：4） 上，控制器會將尾隨位元組作為下一個封包的開頭。管理通訊端 MTU HCI_MAX_FRAME_SIZE，因此params_len這種方式可以達到大約 1KB。提交 03f1700b9b4d （藍牙：MGMT：
    拒絕格式錯誤的 HCI_CMD_SYNC 命令） 僅使params_len符合訊息長度，但仍接受符合訊息但不符合標頭欄位的值。拒絕不符合標頭欄位的params_len。（CVE-2026-80760）

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

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

  - afs： 修正未取消的 rxrpc OOB 訊息處理常式 修正 AFS 以取消其 OOB 訊息處理 （通常是為了回應安全挑戰）。此外，將 OOB 訊息處理移至 afs_wq，以便也等候，並讓 OOB 處理常式在網路命名空間不再存在時傳回。（CVE-2026-80885）

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

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

  - Opennebula v6.10.0.1 自訂驗證器驅動程式中的跨網站指令碼 （XSS） 漏洞允許攻擊者透過特製的有效負載執行任意 Web 腳本或 HTML。（CVE-2025-56534）

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

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

  - drm/amdkfd：在idr_alloc之前驗證 CRIU 還原的 ID KFD CRIU 還原流程會從使用者空間還原先前儲存的物件 ID。對於事件還原：kfd_criu_restore_event（） -> create_signal_event（） / create_other_event（） -> allocate_event_notification_slot（） -> idr_alloc（...， *restore_id， *restore_id + 1， ...）對於 BO 還原：criu_restore_memory_of_gpu（） -> idr_alloc（...， bo_priv->idr_handle， ...）在這兩種情況下，還原的 ID 都來自使用者空間提供的 CRIU 資料。idr_alloc（） 預期 ID 範圍值符合帶正負號的 int 限制。如果還原的 ID 大於 INT_MAX，則可以在 IDR 層中觸發 WARN。核心警告是不可取的，因為它會列印警告追蹤，並可能在啟用 panic_on_warn 的系統上導致錯誤或重新啟動。Smatch 報告這些路徑允許未檢查的使用者空間值到達 idr_alloc（）。在中使用還原的 ID 之前新增INT_MAX驗證： - kfd_criu_restore_event（） - criu_restore_memory_of_gpu（） 如果還原的 ID 無效，請傳回 -EINVAL。這可防止無效還原資料到達 IDR 層，並避免 WARN 觸發路徑，同時保持有效的還原行為不變。（CVE-2026-80870）

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

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

  - iommu/iommufd：修正與 iopt_map_file_pages iommufd_ioas_change_process（） 爭用時iommufd_ioas_change_process中的 NULL 指標解除參照，反覆運算每個 IOAS 區域，同時僅保留每個 IOAS iova_rwsem，因此它假設每個區域都有一個非 NULL 頁面指標。當該假設與 iopt_map_file_pages（） 同時執行時，該假設可能是錯誤的。iopt_map_pages（） 分兩個階段執行。它會先建立區域，並將其插入 iova_rwsem 下的間隔樹狀結構中，而區域>頁仍為 NULL。然後，它會iova_rwsem下放，然後填滿domains_rwsem下的區域>頁。這會在區域建立和區域>頁填充之間留下一個窗口，並發 iommufd_ioas_change_process（） 可以觀察該區域並取消參照 NULL 區域>頁指標，從而導致 NULL 指標解除參照： 錯誤：核心 NULL 指標解除參照，位址：
    00000000000000000c0 #PF：核心模式下的主管讀取存取權 #PF：error_code（0x0000） - 不存在頁面 PGD 4b655067 P4D 4b655067 PUD 0 哎呀：哎呀：0000 [#1] SMP NOPTI CPU：0 UID：0 PID：11841 通訊：syz.。 1.628 未受 7.1.0 #3 污染 PREEMPT（完整） 硬體名稱：QEMU Ubuntu 24.04 PC v2 （i440FX + PIIX， arch_caps fix， 1996）， BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP： 0010：iommufd_ioas_change_process+0x419/0xd50 drivers/iommu/iommufd/ioas.c：538 程式碼： 48 89 c3 48 85 c0 0f 84 cc 00 00 00 e8 10 f5 cb fd 48 8d 7b 68 e8 a7 b5 eb fd 48 8b 6b 68 48 8d bd c0 00 00 00 e8 17 b2 eb fd <8b> ad c0 00 00 00 bf 01 00 00 00 89 ee e8 85 ef cb fd 83 fd 01 74 RSP： 0018：ffffc90015c17d28 EFLAGS：00010246 RAX：ffff8880186d5328 RBX：
    ffff88801d25e240 RCX：0000000080000000 RDX：00000000000002d7 RSI：ffffffff83ba9e10 RDI：0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 R08R09R10R11
    ffffffff83ba9e29 R12： ffff88802e216008 R13： ffff88802e216000 R14： 0000000000000001 R15： 00000000000000000 FS： 00007f4aea3f66c0（0000） GS：ffff8880b1fa1000（0000） knlGS：000000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：00000000000000000c0 CR3：000000004b75c000 CR4：0000000000350ef0 呼叫追蹤： <TASK> iommufd_fops_ioctl+0x287/0x400 drivers/iommu/iommufd/main.c：533 vfs_ioctl fs/ioctl.c：51 [內嵌]
    __do_sys_ioctl fs/ioctl.c：597 [內嵌] __se_sys_ioctl fs/ioctl.c：583 [內嵌] __x64_sys_ioctl+0x120/0x170 fs/ioctl.c：583 x64_sys_call+0x1092/0x1fb0 arch/x86/include/generated/asm/syscalls_64.h：17 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [內嵌] do_syscall_64+0x10a/0x680 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP： 0033：0x7f4aec1a82bd 代碼：ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP： 002b：00007f4aea3f6018 EFLAGS：00000246 ORIG_RAX：0000000000000010 RAX：ffffffffffffffda RBX：00007f4aec436090 RCX：00007f4aec1a82bd RDX：
    0000200000000180 RSI：00000000000003b92 RDI：0000000000000003 RBP：00007f4aec250295 R08： 000000000000000000 R09： 000000000000000000 R10： 000 0000000000000246 R12R130000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 R11
    00007f4aec436128 R14： 00007f4aec436090 R15： 00007ffd04ef23e0 </TASK> 連結於： CR2：
    00000000000000000c0 ---[ 結束追蹤 00000000000000000000 ]--- RIP： 0010：iommufd_ioas_change_process+0x419/0xd50 drivers/iommu/iommufd/ioas.c：538 代碼： 48 89 c3 48 85 c0 0f 84 cc 00 00 00 e8 10 f5 cb fd 48 8d 7b 68 e8 a7 b5 eb fd 48 8b 6b 68 48 8d bd c0 00 00 00 e8 17 b2 eb fd <8b> ad c0 00 00 00 00 bf 01 00 00 00 89 ee e8 85 efcb fd 83 fd 01 74 RSP：0018：ffffc90015c17d28 EFLAGS：00010246 RAX：ffff8880186d5328 RBX：
    ffff88801d25e240 RCX：0000000080000000 RDX：00000000000002d7 RSI：ffffffff83ba9e10 RDI：0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 R08R09R10R11
    ffffffff83ba9e29 R12： ffff88802e216008 R13： ffff88802e216000 R14： 0000000000000001 R15： 0000000000000000 FS： 00007f4aea3f66c0（000 ---truncated--- （CVE-2026-80817）

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

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

  - ntopng 之前 6.7.260717 無法在刪除端點和收件者 REST v2 處理常式中執行授權檢查。經過驗證的非管理員使用者可以發出 POST 要求，以不可逆轉的方式刪除所有已設定的通知端點和收件者，從而使所有警示靜音。（CVE-2026-86090）

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

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

  - 在 environment-modules 中發現缺陷。本機攻擊者可將惡意命名的模組檔案放置在受害者的「MODULEPATH」可見位置，藉此利用此弱點。當受害者將 Bash 完成用於「module」或「ml」命令時，包含殼層中繼字元的惡意模組名稱會被評估為命令。這可能會導致在完整使用者的殼層中執行任意命令，進而影響其機密性、完整性和可用性。（CVE-2026-85013）

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

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

  - MongoDB Server 的查詢執行引擎中的一個問題可能允許具有讀取和寫入權限的已驗證使用者在針對時間序列集合執行特定查詢時，在釋放基礎記憶體後導致使用內部參照。這可能會導致伺服器損毀，或查詢結果中釋放的記憶體內容洩露。（CVE-2026-18711）

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

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

  - drm/vmwgfx：將check_add_overflow用於著色器大小 + 位移繫結 vmw_shader_define（） 會針對使用者提供的著色器視窗驗證其支援緩衝區，UAPI 中__u64 （u64）buffer->tbo.base.size < （u64）size + （u64）offset drm_vmw_shader_create_arg：：offset;當它接近 U64_MAX 時，未帶正負號的加法會換行，而產生的微小值會通過檢查。然後，不受限制的偏移會儲存在 res->guest_memory_offset 中，並轉送至主機 SVGA 著色器建立命令。使用 check_add_overflow（） 來偵測包裝，並將產生的端點與緩衝區大小進行比較。（CVE-2026-80887）

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

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

  - KVM：arm64：nv：插入的巢狀 SError 例外狀況的寫入ESR_EL2 kvm_inject_el2_exception（） 寫入ESR_EL2同步例外，但不寫入 SError。enter_exception64（） 不會寫入任何異常類型的ESR_ELx，因此會捨棄建構的症候群。採用巢狀 SError 的客體 L2 Hypervisor 會觀察過時的ESR_EL2。這會影響 kvm_inject_nested_serror（） 和 kvm_inject_nested_sea（） 中的 EASE 路徑。為except_type_serror寫ESR_EL2，匹配except_type_sync。（CVE-2026-80873）

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

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

  - nvmet： pci-epf：將CQ ref放在create_cq對應失敗nvmet_pci_epf_create_cq（）呼叫nvmet_cq_create（）上，其會在控制器上取得參照並安裝完成佇列。如果後續的 PCI 位址空間對應失敗或傳回太小的部分對應，則函式會跳至 err_internal/err_unmap_queue，而不呼叫 nvmet_cq_put（） 。nvmet_pci_epf_delete_cq（） 中的比對是在 NVMET_PCI_EPF_Q_LIVE 上進行門控的，只有在映射成功後才會設定，因此 teardown 永遠不會釋放這些參照。因此，以失敗的 PRP1/pci_addr 驅動建立 IO CQ 命令的遠端 PCI 主機會在每次嘗試時洩漏 CQ 和控制器參照。刪除對應失敗路徑上的CQ參照。err_internal 和 err_unmap_queue 標籤只有在 nvmet_cq_create（） 成功後才能存取，因此這會正確配對建立/放置。（CVE-2026-80821）

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

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

  - futex：修正初始 mm->futex.phash.ref 分配上的爭用 futex_hash_allocate（） 分配 mm->futex.phash.ref，而不進行任何鎖定。提交 d9b05321e21e （futex： 將 futex_hash_free（） 移回
    __mmput（）） 將分配移至此處，並假設進程此時只有一個執行緒。
    提交 ee9dce44362b （futex：刪除私有預設雜湊配置的CLONE_THREAD要求） 擴大了 need_futex_hash_allocate_default（） 以涵蓋任何CLONE_VM複製，但遺漏了 vfork，因為父項已暫停且無法爭用。一旦 vfork 巢狀，這就不再成立。如果 vfork 子項再次呼叫 vfork，然後使用 SIGKILL 終止，則父項會從其 vfork 等候中釋放出來，並與相同 mm 中的孫項同時執行。他們都沒有經過 futex_hash_allocate_default（）。當兩者同時呼叫 prctl（PR_FUTEX_HASH， PR_FUTEX_HASH_SET_SLOTS） 時，每個都會將 mm->futex.phash.ref 視為 NULL，並儲存自己的 percpu 計數器。只有最後一家商店倖存下來。首先儲存的計數器無法再從 mm 存取，因此 __futex_ref_atomic_end（） 看不到其上的參照。然後，仍然具有參照的私有雜湊會被視為失效並釋放，而仍保留其中一個儲存貯體的任務會寫入 futex_q_lock（） 中釋放的記憶體。使用 cmpxchg（） 儲存計數器一次，讓失敗者自己free_percpu（）。初始參照必須在存放區之前取得，否則另一個工作可以在計數器仍為 0 時安裝私有雜湊。（CVE-2026-80775）

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

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

  - 已解決 Linux 核心中的下列弱點：HID: huawei: fix missing hid_is_usb() check to_usb_interface() can only be used on a hid_device whose parent is really USB; uhid can create devices that identify as being on BUS_USB, but don't actually have a USB parent. Fix the use of to_usb_interface() without a hid_is_usb() check. I have verified that it is currently possible to trigger a kernel splat due to this bug in an ASAN build, and that this commit fixes the issue. (CVE-2026-80773)

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

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

  - drm/xe/oa：修正 OA 設定發出失敗時的同步項目洩漏 xe_oa_emit_oa_config（） 僅在其成功路徑上釋放同步項目和同步陣列。當它在不歸路點（柵欄分配、配置緩衝區分配或批量提交）之前失敗時，它會在不接觸流>同步的情況下返回。資料流開啟路徑會處理呼叫端中的這類失敗，但 xe_oa_config_locked（） 會傳播錯誤而不進行任何清除，因此會洩漏剖析項目所保留的同步陣列和柵欄參考。
    下一個組態 ioctl 會覆寫 stream->syncs，使記憶體永遠無法連線。當 xe_oa_emit_oa_config（） 失敗時，清理已剖析的同步處理，以符合資料流開啟錯誤路徑所完成的清理作業。
    （從提交 8af97b3da2cfce04e6b457c6eb17ed3c1daf912b 中挑選）（CVE-2026-80903）

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

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

  - iommufd：修正在替換 iommufd_hwpt_replace_device（） 呼叫時傳遞給iommufd_auto_response_faults的錯誤 hwpt：iommufd_auto_response_faults（hwpt， old_handle）;將 *new* hwpt 與裝置的 *old* 網域的控點一起傳遞。這應該是參數不相符： 1. 從語義上講，iommufd_auto_response_faults（x， handle） 會掃描 x->fault 的傳遞清單和回應 xarray 以尋找符合 handle 的群組。群組會在錯誤傳遞時附加的 hwpt 下排入佇列。old_handle 是在網域切換之前*擷取的，因此其群組位於舊的 >fault 上，而不是新的 hwpt->fault 上。2.
    從歷史上看，第一個論點是古老的。此常式是由提交 b7d8833677ba 引入的 （iommufd：
    fault-capable hwpt attach/detach/replace） 作為 fault.c 中的 __fault_domain_replace_dev（），正確調用 iommufd_auto_response_faults（old， curr）。提交 fb21b1568ada （iommufd：使attach_handle通用而不是特定於故障） 將其移動到 device.c 中的 iommufd_hwpt_replace_device（） 中並將其交換為 hwpt。這應該是重構迴歸，而不是故意的改變。透過傳遞舊的來解決此問題。
    (CVE-2026-80894)

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

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

  - serial： msm： 停用核心主控台 UART 的 DMA 目前，從使用者空間和核心並行寫入主控台可能會觸發爭用情形，導致重複列印相同訊息的無限迴圈。這最有可能發生在系統啟動或關閉期間，當 init 系統啟動/停止大量與各種核心程式碼互動的系統服務時。當使用者空間寫入 TTY 裝置時，驅動程式會起始非同步 DMA 傳輸，並釋放埠鎖定。同時，核心 printk 路徑可能會取得連接埠鎖定，並針對 PIO 重新設定 UART 控制器，而不需要等候 DMA 作業完成。似乎這種衝突導致 DMA 引擎報告的進度為零，因此相同的文本會一遍又一遍地打印到控制台。對於核心主控台，我們想要一個可靠的輸出路徑，即使在當機等情況下也能正常運作。因此，無需實作複雜的程式碼來將核心主控台寫入常式與使用者空間 DMA 寫入常式同步，只需停用主控台 UART 執行個體的 DMA。許多其他序列驅動程式中也存在類似的檢查，例如 8250_port.c、imx.c、sh-sci.c 等。CVE-2026-80886

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

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

  - ntfs3：使用 alloc_page 配置 iomap inline_data 這修正了 iomap_write_end_inline 中報告的錯誤：
    iomap_inline_data_valid檢查inline_data是否適合頁面。如果使用 kmemdup 配置inline_data，則無法保證它是頁面對齊的，因此檢查有時會失敗。使用 alloc_page 進行配置，以確保其頁面對齊。（CVE-2026-80868）

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

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

  - crypto：xilinx-trng - 移除crypto_rng介面 實作 crypto_rng 介面沒有任何目的，因為它在實踐中沒有使用。它也被從其他驅動程序中刪除。只需將其移除即可。這就留下了實際使用的 hwrng。使用「Cc stable」標記，因為這會移除錯誤：- xtrng_trng_generate（） 有時即使沒有填入所有位元組，也會傳回成功。- xtrng_trng_generate（） 和 xtrng_hwrng_trng_read（） 可能會同時執行並相互干擾，因為 xtrng_hwrng_trng_read（） 中的鎖定碼已破解。（CVE-2026-80871）

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

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

  - ocfs2：修正 ocfs2_dio_end_io_write 中的循環鎖定相依性 循環鎖定相依性涉及 INODE_ALLOC_SYSTEM_INODE、EXTENT_ALLOC_SYSTEM_INODE 和 ORPHAN_DIR_SYSTEM_INODE。1. ocfs2_mknod（） 取得INODE_ALLOC然後EXTENT_ALLOC。2. ocfs2_dio_end_io_write（） 取得未寫入範圍的EXTENT_ALLOC，然後透過 ocfs2_del_inode_from_orphan（） ORPHAN_DIR，同時仍持有 EXTENT_ALLOC。3.
    ocfs2_wipe_inode（） 取得ORPHAN_DIR然後透過 ocfs2_remove_inode INODE_ALLOC。在取得ORPHAN_DIR之前釋放分配內容 （釋放 EXTENT_ALLOC），以打破 ocfs2_dio_end_io_write（） 中的循環。警告：偵測到可能的循環鎖定相依性
    ------------------------------------------------------ 正在嘗試取得鎖定：ffff8881e78b33a0 （&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]）{+.+.}-{4:4}， at： ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c：1299 但任務已經持有鎖定： ffff8881e78b4fa0 （&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]）{+.+.}-{4:4}， at： ocfs2_evict_inode+0xe97/0x43b0 fs/ocfs2/inode.c：1299 現有的相依性鏈結 （以相反的順序排列） 為： -> #2 （&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]）{+.+.}-{4:4}： inode_lock include/linux/fs.h：1029 [內聯] ocfs2_del_inode_from_orphan+0x12e/0x7a0 fs/ocfs2/namei.c：2728 ocfs2_dio_end_io+0xf9c/0x1370 fs/ocfs2/aops.c：2418 dio_complete+0x25b/0x790 fs/direct-io.c：281 -> #1 （&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]）{+.+.}-{4:4}： inode_lock include/linux/fs.h：1029 [內嵌] ocfs2_reserve_suballoc_bits+0x16d/0x4840 fs/ocfs2/suballoc.c：882 ocfs2_reserve_new_metadata_blocks+0x415/0x9a0 fs/ocfs2/suballoc.c：1078 ocfs2_mknod+0x10f3/0x2260 fs/ocfs2/namei.c：351 -> #0 （&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]）{+.+.}-{4:4}:
    __lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c：5237 lock_acquire+0x106/0x350 kernel/locking/lockdep.c：5868 down_write+0x96/0x200 kernel/locking/rwsem.c：1625 inode_lock include/linux/fs.h：1029 [inline] ocfs2_remove_inode fs/ocfs2/inode.c：733 [inline] ocfs2_wipe_inode fs/ocfs2/inode.c：896 [inline] ocfs2_delete_inode fs/ocfs2/inode.c：1157 [inline] ocfs2_evict_inode+0x1539/0x43b0 fs/ocfs2/inode.c：1299 鏈結存在：
    &ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE] --> &ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]
    --> &ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] 可能的不安全鎖定場景：CPU0 CPU1 ---- ---- lock（&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]）;
    lock（&ocfs2_sysfile_lock_key[EXTENT_ALLOC_SYSTEM_INODE]）;
    lock（&ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE]）;
    lock（&ocfs2_sysfile_lock_key[INODE_ALLOC_SYSTEM_INODE]）;鎖死 *** （CVE-2026-80879)

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

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

  - ipvs：在 TCP 狀態查詢中使用剖析的傳輸位移 TCP 狀態處理會重新剖析 skb 以尋找 TCP 標頭。對於 IPv6，它使用 sizeof（struct ipv6hdr），而周圍的 IPVS 程式碼已經使用 ip_vs_fill_iph_skb（） 剖析了封包，並且在 iph.len 中具有真正的傳輸標頭偏移量。這使得當 IPv6 封包攜帶擴充標頭時，TCP 狀態處理會查看錯誤的位元組。讀取 TCP 標頭時，使用從 ip_vs_set_state（） 傳下來的剖析傳輸偏移。對於 IPv4 和沒有延伸標頭的 IPv6 封包，傳遞的位移會符合先前的值。（CVE-2026-80875）

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

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

  - ALSA： FCP：將私人 URB 用於通知端點 fcp_init_notify（） 使用的 mixer->urb，snd_usb_mixer_status_create（） 會配置給選擇性的 UAC2 狀態中斷端點，而 mixer.c 會終止、重新提交和釋放。在具有該端點的裝置上，fcp_init_notify（） 已設定的提前傳回會在狀態 URB 上觸發，並在不執行任何動作的情況下傳回成功。不會提交任何 FCP 通知 URB，而且 cmd_done 會保持為零，因為它會在該早期傳回之後初始化，而且沒有其他任何地方。fcp_init（） 然後發出 init1_opcode，wait_for_completion_timeout（） 將當機新增至歸零的 wait.head。
    fcp_cleanup_urb（） 也會終止並釋放 mixer.c 的狀態 URB。在 fcp_data 中使用單獨的 URB，並在配置 fcp_data 的 fcp_init_private（） 中初始化cmd_done。透過 fcp_reinit（） 暫停之後再次達到 fcp_init_notify（），而 fcp_notify（） 中的 URB 終止路徑會完成cmd_done，留下過時的計數，可在裝置 ACK 之前滿足下一個命令的等候時間。使用 reinit_completion（） 清除它。（CVE-2026-80816）

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

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

  - 藍牙：hci_aml：驗證韌體區段長度 aml_download_firmware（） 會從韌體標頭讀取兩個長度，並使用它們來建立指標，然後再檢查標頭和區段資料是否存在。截斷或不一致的韌體映像可能會讓驅動程式在建構 TCI 命令時讀取過去的韌體>資料。拒絕短於標頭的映像，並確保 ICCM 和 DCCM 範圍符合載入的韌體，再下載任一區段。（CVE-2026-80759）

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

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

  - MongoDB Server 的 JavaScript 腳本引擎中的一個問題可能允許具有寫入權限的已驗證使用者透過在內部維護週期期間處理的特製儲存值，導致他們控制的程式碼在其他使用者的查詢範圍內執行。這可能會導致影響其他使用者的查詢結果損毀，以及針對其在相同資料庫上的作業的拒絕服務。影響僅限於指令碼引擎的執行沙箱，該沙箱不提供對資料庫、檔案系統或網路資源的存取權。（CVE-2026-18708）

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

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

  - crypto： tegra - 當 ccm 的輸入緩衝區配置失敗時傳回 ENOMEM 確保在 tegra_ccm_do_one_req 中輸入緩衝區配置失敗時設定 ENOMEMCVE-2026-80882 錯誤值。

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

ID	名稱	嚴重性
343472	Linux Distros 未修補弱點：CVE-2026-18888	high
343471	Linux Distros 未修補弱點：CVE-2026-80853	medium
343470	Linux Distros 未修補弱點：CVE-2026-80813	medium
343469	Linux Distros 未修補弱點：CVE-2026-80867	medium
343468	Linux Distros 未修補弱點：CVE-2026-80818	medium
343467	Linux Distros 未修補弱點：CVE-2026-86227	low
343466	Linux Distros 未修補弱點：CVE-2026-80787	medium
343465	Linux Distros 未修補弱點：CVE-2026-80769	medium
343464	Linux Distros 未修補弱點：CVE-2026-80898	medium
343463	Linux Distros 未修補弱點：CVE-2026-80880	medium
343462	Linux Distros 未修補弱點：CVE-2026-80900	medium
343461	Linux Distros 未修補弱點：CVE-2026-80895	medium
343460	Linux Distros 未修補弱點：CVE-2026-18712	high
343459	Linux Distros 未修補弱點：CVE-2026-18707	medium
343458	Linux Distros 未修補弱點：CVE-2026-80865	medium
343457	Linux Distros 未修補弱點：CVE-2026-80911	medium
343456	Linux Distros 未修補弱點：CVE-2026-80810	medium
343455	Linux Distros 未修補弱點：CVE-2026-80778	medium
343454	Linux Distros 未修補弱點：CVE-2026-80877	medium
343453	Linux Distros 未修補弱點：CVE-2026-80881	medium
343452	Linux Distros 未修補弱點：CVE-2026-80815	medium
343451	Linux Distros 未修補弱點：CVE-2026-76578	critical
343450	Linux Distros 未修補弱點：CVE-2026-86091	high
343449	Linux Distros 未修補弱點：CVE-2026-80874	medium
343448	Linux Distros 未修補弱點：CVE-2026-80869	medium
343447	Linux Distros 未修補弱點：CVE-2026-80897	medium
343446	Linux Distros 未修補弱點：CVE-2026-80760	medium
343445	Linux Distros 未修補弱點：CVE-2026-80885	medium
343444	Linux Distros 未修補弱點：CVE-2025-56534	medium
343443	Linux Distros 未修補弱點：CVE-2026-80870	medium
343442	Linux Distros 未修補弱點：CVE-2026-80817	medium
343441	Linux Distros 未修補弱點：CVE-2026-86090	high
343440	Linux Distros 未修補弱點：CVE-2026-85013	high
343439	Linux Distros 未修補弱點：CVE-2026-18711	high
343438	Linux Distros 未修補弱點：CVE-2026-80887	medium
343437	Linux Distros 未修補弱點：CVE-2026-80873	medium
343436	Linux Distros 未修補弱點：CVE-2026-80821	medium
343435	Linux Distros 未修補弱點：CVE-2026-80775	medium
343434	Linux Distros 未修補弱點：CVE-2026-80773	medium
343433	Linux Distros 未修補弱點：CVE-2026-80903	medium
343432	Linux Distros 未修補弱點：CVE-2026-80894	medium
343431	Linux Distros 未修補弱點：CVE-2026-80886	medium
343430	Linux Distros 未修補弱點：CVE-2026-80868	medium
343429	Linux Distros 未修補弱點：CVE-2026-80871	medium
343428	Linux Distros 未修補弱點：CVE-2026-80879	medium
343427	Linux Distros 未修補弱點：CVE-2026-80875	medium
343426	Linux Distros 未修補弱點：CVE-2026-80816	medium
343425	Linux Distros 未修補弱點：CVE-2026-80759	medium
343424	Linux Distros 未修補弱點：CVE-2026-18708	medium
343423	Linux Distros 未修補弱點：CVE-2026-80882	medium

偵測

Nessus 的 Misc. 系列

high

medium

medium

medium

medium

low

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

critical

high

medium

medium

medium

medium

medium

medium

medium

medium

high

high

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium