Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - IB/hfi1：修复 credit-return mmap PIO_CRED hfi1_file_mmap（） 的PIO_CRED情况必须向用户空间提供包含此上下文条目的单个 credit-return 页面。一旦硬件发送上下文索引达到 64 或 128，该页面就是每个节点信用回报分配的第二页或第三页，因此下面的失败是间歇性的：当条目落在第一页时，偏移量为零，一切正常。有两件事是错误的。首先，cr_page_offset 是字节偏移，但 .va 是 credit_return * 的结构，因此添加它是指针算术，并按 sizeof（struct credit_return） == 64 缩放偏移量。然后，memvirt 通过 10240 字节的分配到达 256 KiB 或 512 KiB。通过 IOMMU 转换，该地址位于 vmalloc 范围之内但不在vm_area内，因此 dma_mmap_coherent（） -> iommu_dma_mmap（） 不找到任何页面，vmalloc_to_pfn（） 返回 page_to_pfn（NULL），而 remap_pfn_range（） 在 MAXPHYADDR 上方安装一个框架。第一个用户读取随后执行：psm2_ep_open_pr：地址 7a14d007e000 PGD 800000013886a067 P4D 800000013886a067 PUD 13886b067 PMD 13886c067 PTE 800049168e911235 哎呀：页表错误：000d [#1] SMP PTI 其次，在算术更正后仍然是错误的，dma_mmap_coherent（） 描述整个一致的缓冲区并使用 vma->vm_pgoff 选择其中的页面。偏移 cpu_addr 无任何效果：对于 vmap'd 分配，iommu_dma_mmap（） 仅使用 cpu_addr 定位vm_area，然后映射 pages[vm_pgoff]，hfi1_file_mmap（） 刚刚将其设为 0。因此，用户空间始终收到第一个 credit-return 页面，每个 credit-return 读取都针对错误的上下文，并永久发送 PIO 停止。按预期使用 DMA API：传递分配的基础及其完整长度，然后选择具有vm_pgoff的页面。需要单独的长度，因为 memlen 必须不断描述现有大小检查的 VMA。由于 dma_direct_mmap（） 将相同的vm_pgoff添加到基础 pfn，因此 dma-direct 路径也保持正确。在 Dell T7610 （Xeon E5-2650 v2，DMA-FQ 模式下的 Intel IOMMU）与 Threadripper PRO 3995WX 对等机（均为 Omni-Path 100）进行测试。
    在此更改之前，psm2_ep_open（） 会造成内核 oops;只有算术修正后的 psm2_ep_open（） 成功，但任何使用发送 PIO 的传输挂起，PSM2_SDMA=2（禁用发送 PIO）会正常完成，而 PSM2_SDMA=0（仅发送 PIO）每次都会挂起。通过此更改，发送 PIO、发送 DMA 和默认的混合模式全部起作用。（CVE-2026-98216）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

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

  - IB/hfi1：修正PIO_CRED信用回報 mmap hfi1_file_mmap（） 的PIO_CRED案例必須將使用者空間提供包含此上下文項目的單一信用回報頁面。一旦硬體傳送內容索引達到 64 或 128，該頁面就是每個節點點數回報分配的第二頁或第三頁，因此下面的失敗是間歇性的：當項目落在第一頁時，偏移量為零，一切正常。有兩件事是錯誤的。首先，cr_page_offset 是位元組偏移，但 .va 是 * credit_return結構，因此添加它是指標算術，並按 sizeof（struct credit_return） == 64 縮放偏移量。然後，memvirt 會透過 10240 位元組的配置，登陸 256 KiB 或 512 KiB。使用 IOMMU 轉換時，該位址位於 vmalloc 範圍內，但不在vm_area內，因此 dma_mmap_coherent（） -> iommu_dma_mmap（） 找不到頁面，vmalloc_to_pfn（） 傳回 page_to_pfn（NULL），而 remap_pfn_range（） 會在 MAXPHYADDR 上方安裝一個框架。然後，第一個使用者讀取會採取： psm2_ep_open_pr：位址 7a14d007e000 PGD 800000013886a067 P4D 800000013886a067 PUD 13886b067 PMD 13886c067 PTE 800049168e911235 哎呀：錯誤頁面表格：000d [#1] SMP PTI 其次，一旦算術更正，仍然錯誤，dma_mmap_coherent（） 描述了一個完整的連貫緩衝區，並使用 vma->vm_pgoff 選擇其中的頁面。偏移cpu_addr沒有效果：對於 vmap'd 分配 iommu_dma_mmap（） 僅使用 cpu_addr 來定位vm_area，然後映射 pages[vm_pgoff]，而 hfi1_file_mmap（） 剛剛將其設定為 0。因此，使用者空間一律會收到第一個信用回報頁面，每次信用讀取都是針對錯誤的上下文，並永遠發送 PIO 停止。如預期使用 DMA API：傳遞分配的基數及其完整長度，然後選取具有vm_pgoff的頁面。需要單獨的長度，因為 memlen 必須不斷描述現有大小檢查的 VMA。dma 直接路徑也會保持正確，因為 dma_direct_mmap（） 會將相同的vm_pgoff新增至基底 pfn。在 Dell T7610 （Xeon E5-2650 v2，DMA-FQ 模式下的 Intel IOMMU）上針對 Threadripper PRO 3995WX 對等體（均為 Omni-Path 100）進行測試。
    在此變更之前，psm2_ep_open（） Oops核心;只有算術更正的 psm2_ep_open（） 成功，但任何使用傳送 PIO 的傳輸都會掛起，PSM2_SDMA=2 （停用傳送 PIO） 會正常完成，而 PSM2_SDMA=0 （僅傳送 PIO） 每次都會掛起。透過此變更，傳送 PIO、傳送 DMA 和預設混合模式都可以運作。（CVE-2026-98216）

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

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - IB/hfi1:クレジットリターン mmap hfi1_file_mmap() のPIO_CREDケースでは、ユーザー空間にこのコンテキストのエントリを保持する単一のクレジットリターンページを渡さなければならないPIO_CREDを修正します。このページは、ハードウェア送信コンテキストインデックスが64または128に達すると、ノードごとのクレジットリターン割り当ての2ページ目または3ページ目であるため、以下の失敗は断続的です:エントリが最初のページに到達すると、オフセットはゼロになり、すべてが機能します。2つのことが間違っています。まず、cr_page_offsetはバイトオフセットですが、.vaは*credit_return構造体であるため、それを追加するとポインター算術演算であり、sizeof(struct credit_return) == 64でオフセットがスケーリングされます。その後、memvirt は 10240 バイトの割り当てを超えて 256 KiB または 512 KiB を着地します。IOMMU 変換では、そのアドレスは vmalloc 範囲内にありますが、vm_areaにはないため、dma_mmap_coherent() -> iommu_dma_mmap() はページを検出せず、vmalloc_to_pfn() は page_to_pfn(NULL) を返し、remap_pfn_range() は MAXPHYADDR の上にフレームをインストールします。その後、最初のユーザー読み込みを行います:psm2_ep_open_pr:アドレス 7a14d007e000 PGD 800000013886a067 P4D 800000013886a067 PUD 13886b067 PMD 13886c067 PTE 800049168e911235 Oops:不良ページテーブル:000d [#1] SMP PTI 第二に、算術演算が修正されると依然として間違っていますが、dma_mmap_coherent() は一貫したバッファ全体を記述し、vma->vm_pgoff でその中のページを選択します。cpu_addrオフセットは効果がありません:vmap'd 割り当ての場合、iommu_dma_mmap() は cpu_addr を使用して vm_area の場所を特定し、次に hfi1_file_mmap() が 0 に設定したばかりの pages[vm_pgoff] をマッピングします。したがってユーザー空間は常に最初のクレジットリターンページを受信し、すべてのクレジット読み取りは間違ったコンテキストに対するものであり、永久に PIO ストールを送信します。DMA APIを意図したとおりに使用します:割り当てのベースをその全長で渡し、vm_pgoffのあるページを選択します。memlen が既存のサイズチェックのために VMA を記述し続ける必要があるため、別の長さが必要です。dma_direct_mmap() がベース pfn に同じvm_pgoffを追加するため、dma-direct パスも正しいままになります。Dell T7610 (Xeon E5-2650 v2、DMA-FQモードのIntel IOMMU)で、どちらもOmni-Path 100のThreadripper PRO 3995WXピアに対してテストしました。
    この変更の前にpsm2_ep_open()はカーネルをOopsします。補正された算術 psm2_ep_open() のみが成功しますが、PIO 送信を使用する転送がハングすると、PSM2_SDMA=2(PIO 送信が無効化)が正常に完了しますが、PSM2_SDMA=0(PIO 送信のみ)が毎回ハングします。この変更により、PIO 送信、DMA 送信、およびデフォルトの混合モードはすべて機能します。(CVE-2026-98216)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The remote Debian 13 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-6568 advisory.

    - -------------------------------------------------------------------------     Debian Security Advisory DSA-6568-1                   security@debian.org     https://www.debian.org/security/                     Salvatore Bonaccorso     October 16, 2026                      https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    Package        : linux     CVE ID         : CVE-2025-38204 CVE-2025-40158 CVE-2026-52988 CVE-2026-72315                      CVE-2026-72463 CVE-2026-74347 CVE-2026-80935 CVE-2026-80937                      CVE-2026-80939 CVE-2026-80980 CVE-2026-81016 CVE-2026-89437                      CVE-2026-89441 CVE-2026-89445 CVE-2026-89452 CVE-2026-89467                      CVE-2026-89500 CVE-2026-89503 CVE-2026-89520 CVE-2026-89527                      CVE-2026-89633 CVE-2026-89638 CVE-2026-89766 CVE-2026-89795                      CVE-2026-89797 CVE-2026-89806 CVE-2026-89827 CVE-2026-89832                      CVE-2026-89837 CVE-2026-89838 CVE-2026-89840 CVE-2026-89859                      CVE-2026-89868 CVE-2026-89912 CVE-2026-89921 CVE-2026-89956                      CVE-2026-89971 CVE-2026-89972 CVE-2026-89996 CVE-2026-90002                      CVE-2026-90013 CVE-2026-90016 CVE-2026-90023 CVE-2026-90029                      CVE-2026-90030 CVE-2026-90146 CVE-2026-93179 CVE-2026-93196                      CVE-2026-93199 CVE-2026-93200 CVE-2026-93231 CVE-2026-93243                      CVE-2026-93244 CVE-2026-93285 CVE-2026-97527 CVE-2026-97528                      CVE-2026-97529 CVE-2026-97530 CVE-2026-97531 CVE-2026-97532                      CVE-2026-97534 CVE-2026-97535 CVE-2026-97536 CVE-2026-97537                      CVE-2026-97549 CVE-2026-97558 CVE-2026-97559 CVE-2026-97566                      CVE-2026-97567 CVE-2026-97571 CVE-2026-97574 CVE-2026-97594                      CVE-2026-97597 CVE-2026-97603 CVE-2026-97609 CVE-2026-97615                      CVE-2026-97618 CVE-2026-97619 CVE-2026-97620 CVE-2026-97901                      CVE-2026-97906 CVE-2026-97918 CVE-2026-97919 CVE-2026-97933                      CVE-2026-97934 CVE-2026-97935 CVE-2026-97938 CVE-2026-97939                      CVE-2026-97949 CVE-2026-97950 CVE-2026-98101 CVE-2026-98161                      CVE-2026-98167 CVE-2026-98168 CVE-2026-98169 CVE-2026-98170                      CVE-2026-98171 CVE-2026-98172 CVE-2026-98173 CVE-2026-98174                      CVE-2026-98175 CVE-2026-98179 CVE-2026-98181 CVE-2026-98182                      CVE-2026-98184 CVE-2026-98185 CVE-2026-98186 CVE-2026-98187                      CVE-2026-98188 CVE-2026-98189 CVE-2026-98190 CVE-2026-98191                      CVE-2026-98192 CVE-2026-98193 CVE-2026-98194 CVE-2026-98195                      CVE-2026-98196 CVE-2026-98197 CVE-2026-98198 CVE-2026-98199                      CVE-2026-98200 CVE-2026-98201 CVE-2026-98202 CVE-2026-98203                      CVE-2026-98204 CVE-2026-98205 CVE-2026-98206 CVE-2026-98207                      CVE-2026-98208 CVE-2026-98209 CVE-2026-98210 CVE-2026-98211                      CVE-2026-98212 CVE-2026-98213 CVE-2026-98214 CVE-2026-98215                      CVE-2026-98216 CVE-2026-98217 CVE-2026-98218 CVE-2026-98221                      CVE-2026-98222 CVE-2026-98227 CVE-2026-98229 CVE-2026-98230                      CVE-2026-98231 CVE-2026-98232 CVE-2026-98233 CVE-2026-98234                      CVE-2026-98235 CVE-2026-98236 CVE-2026-98237 CVE-2026-98238                      CVE-2026-98239 CVE-2026-98241 CVE-2026-98245 CVE-2026-98246                      CVE-2026-98247 CVE-2026-98248 CVE-2026-98249 CVE-2026-98251                      CVE-2026-98252 CVE-2026-98253 CVE-2026-98254 CVE-2026-98255                      CVE-2026-98257 CVE-2026-98260 CVE-2026-98261 CVE-2026-98262                      CVE-2026-98263 CVE-2026-98264 CVE-2026-98265 CVE-2026-98266                      CVE-2026-98267 CVE-2026-98269 CVE-2026-98270 CVE-2026-98271                      CVE-2026-98272 CVE-2026-98275 CVE-2026-98276 CVE-2026-98282                      CVE-2026-98283 CVE-2026-98287 CVE-2026-98290 CVE-2026-98291                      CVE-2026-98293 CVE-2026-98295 CVE-2026-98297 CVE-2026-98298                      CVE-2026-98299 CVE-2026-98300 CVE-2026-98301 CVE-2026-98302                      CVE-2026-98303 CVE-2026-98306 CVE-2026-98307 CVE-2026-98308                      CVE-2026-98309 CVE-2026-98311 CVE-2026-98312 CVE-2026-98314                      CVE-2026-98316 CVE-2026-98319 CVE-2026-98320 CVE-2026-98322                      CVE-2026-98323 CVE-2026-98325 CVE-2026-98326 CVE-2026-98327                      CVE-2026-98328 CVE-2026-98329 CVE-2026-98331 CVE-2026-98334                      CVE-2026-98335 CVE-2026-98336 CVE-2026-98337 CVE-2026-98339                      CVE-2026-98340 CVE-2026-98342 CVE-2026-98343 CVE-2026-98344                      CVE-2026-98345 CVE-2026-98346 CVE-2026-98347 CVE-2026-98348                      CVE-2026-98349 CVE-2026-98351 CVE-2026-98352 CVE-2026-98354                      CVE-2026-98357 CVE-2026-98358 CVE-2026-98359 CVE-2026-98360                      CVE-2026-98362 CVE-2026-98363 CVE-2026-98365 CVE-2026-98366                      CVE-2026-98367 CVE-2026-98368 CVE-2026-98369 CVE-2026-98370                      CVE-2026-98373 CVE-2026-98374 CVE-2026-98375 CVE-2026-98377                      CVE-2026-98378 CVE-2026-98379 CVE-2026-98380 CVE-2026-98381                      CVE-2026-98382 CVE-2026-98383 CVE-2026-98384 CVE-2026-98386                      CVE-2026-98403 CVE-2026-98406 CVE-2026-98407 CVE-2026-98409                      CVE-2026-98410 CVE-2026-98411 CVE-2026-98412 CVE-2026-98413                      CVE-2026-98416 CVE-2026-98417 CVE-2026-98419 CVE-2026-98421                      CVE-2026-98422 CVE-2026-98423 CVE-2026-98425 CVE-2026-98426                      CVE-2026-98428 CVE-2026-98429 CVE-2026-98430 CVE-2026-98432                      CVE-2026-99999     Debian Bug     : 1149499 1149564 1150891

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For the stable distribution (trixie), these problems have been fixed in     version 6.12.113-1.

    We recommend that you upgrade your linux packages.

    For the detailed security status of linux please refer to its security     tracker page at:
    https://security-tracker.debian.org/tracker/linux

    Further information about Debian Security Advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - IB/hfi1: Fix the PIO_CRED credit-return mmap hfi1_file_mmap()'s PIO_CRED case must hand user space the     single credit-return page that holds this context's entry. That page is the second or third page of the     per-node credit-return allocation once the hardware send context index reaches 64 or 128, so the failure     below is intermittent: when the entry lands on the first page the offset is zero and everything works. Two     things are wrong. First, cr_page_offset is a byte offset but .va is a struct credit_return *, so adding it     is pointer arithmetic and scales the offset by sizeof(struct credit_return) == 64. memvirt then lands 256     KiB or 512 KiB past a 10240-byte allocation. With an IOMMU translating, that address is inside the vmalloc     range but in no vm_area, so dma_mmap_coherent() -> iommu_dma_mmap() finds no pages, vmalloc_to_pfn()     returns page_to_pfn(NULL), and remap_pfn_range() installs a frame above MAXPHYADDR. The first user read     then takes: psm2_ep_open_pr: Corrupted page table at address 7a14d007e000 PGD 800000013886a067 P4D     800000013886a067 PUD 13886b067 PMD 13886c067 PTE 800049168e911235 Oops: Bad pagetable: 000d [#1] SMP PTI     Second, and still wrong once the arithmetic is corrected, dma_mmap_coherent() describes a whole coherent     buffer and selects the page within it with vma->vm_pgoff. Offsetting cpu_addr has no effect: for a vmap'd     allocation iommu_dma_mmap() uses cpu_addr only to locate the vm_area and then maps pages[vm_pgoff], which     hfi1_file_mmap() has just set to 0. User space therefore always receives the first credit-return page,     every credit read is for the wrong context, and send PIO stalls forever. Use the DMA API as intended: pass     the base of the allocation with its full length and select the page with vm_pgoff. A separate length is     needed because memlen must keep describing the VMA for the existing size check. The dma-direct path stays     correct as well, since dma_direct_mmap() adds the same vm_pgoff to the base pfn. Tested on a Dell T7610     (Xeon E5-2650 v2, Intel IOMMU in DMA-FQ mode) against a Threadripper PRO 3995WX peer, both Omni-Path 100.
    Before this change psm2_ep_open() Oopses the kernel; with only the arithmetic corrected psm2_ep_open()     succeeds but any transfer that uses send PIO hangs, PSM2_SDMA=2 (send PIO disabled) completing normally     while PSM2_SDMA=0 (send PIO only) hangs every time. With this change send PIO, send DMA and the default     mixed mode all work. (CVE-2026-98216)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	名稱	產品	系列	已發布	已更新	嚴重性
363172	Linux Distros 未修补的漏洞：CVE-2026-98216	Nessus	Misc.	2026/10/6	2026/10/12	high
363172	Linux Distros 未修補弱點：CVE-2026-98216	Nessus	Misc.	2026/10/6	2026/10/12	high
363172	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98216	Nessus	Misc.	2026/10/6	2026/10/12	high
366507	Debian dsa-6568 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	2026/10/16	2026/10/16	medium
363172	Linux Distros Unpatched Vulnerability : CVE-2026-98216	Nessus	Misc.	2026/10/6	2026/10/12	high

偵測

搜尋 Plugin

high

high

high

medium

high