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

  - net：stmmac：修复 rx 分散-收集支持 当接收到的帧大于 dma_buf_sz 时，DMA 会将其分散到多个 RX 描述符中 （rx Scatter-Gather）。辅助 RX 缓冲区 （sec_page） 仅在拆分标头 （SPH） 处于活动状态时才会进行分配和编程，因此对于常规帧，buffer2 既未分配也未得到有效映射的支持。一旦传入帧溢出 buffer1，DMA 就会将该溢出写入到未映射的辅助缓冲区地址，从而在基于 IOMMU 的平台上触发 SMMU 转换错误： arm-smmu 15000000.iommu： 未处理的上下文错误： fsr=0x402、 iova=0x00000000、 fsynr=0x7f0011、 cbfrsynra=0x1c90cb=11 arm-smmu 15000000.iommu： FSR = 00000402 [format=2 TF]， SID=0x1c90 arm-smmu 15000000.iommu： FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1] 针对可编程独立辅助 RX 的核心上的非 SPH 帧启用分散-收集buffer （GMAC4/XGMAC）：在 stmmac_init_rx_buffers（） 和 stmmac_rx_refill（） 中分配 buffer2 并将其标记为有效，并在缓冲区长度计算中考虑该因素。旧版核心没有set_sec_addr op，因此会禁用 buffer2。由于 buffer2 在页面偏移 0 时传递给 DMA，因此页面池同步窗口会扩大到在每种模式下同时涵盖两个缓冲区：offset 设置为 0，max_len 设置为 dma_buf_sz + stmmac_rx_offset（）。FCS 可跨越 buffer1/buffer2 边界和描述符边界，因此它现在可通过 pskb_trim（） 从组装的帧的末尾剥离，而不是从单个缓冲区剥离，从而避免帧因使缓冲区溢出 1..3 字节而出现无符号下溢。对于单缓冲区帧，XDP 程序不得看到 FCS，因此在程序运行之前将其从 XDP 缓冲区中删除。原生 XDP 当前仅支持单缓冲区（线性）帧。MAC（启用巨型）接受的超大帧通过 buffer2 接收;XDP 程序仅看到 buffer1，因此在 TX/REDIRECT 判定中，该帧被转发截断。计划作为后续行动提供 XDP 多缓冲区支持以处理这种情况。此更改不涵盖AF_XDP零拷贝 RX：
    ZC 队列仍在 DMA 地址 0 处对 buffer2 进行编程（且 XGMAC 没有 buffer2-valid 位），因此超大帧溢出 buffer1 仍可触发相同的 SMMU 转换错误。计划作为后续行动进行处理。（CVE-2026-98803）

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

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

  - net： stmmac：修正 rx Scatter-Gather 支援 當接收的框架大於 dma_buf_sz 時，DMA 會將其分散在多個 RX 描述元 （rx Scatter-Gather） 中。次要 RX 緩衝區 （sec_page） 僅在分割標頭 （SPH） 處於活動狀態時進行配置和編程，因此對於常規幀，緩衝區 2 既未配置，也未由有效映射支援。一旦傳入幀溢位 buffer1，DMA 就會將溢位寫入未映射的輔助緩衝區位址，從而在基於 IOMMU 的平台上觸發 SMMU 轉換錯誤： arm-smmu 15000000.iommu： 未處理的上下文錯誤： fsr=0x402、 iova=0x00000000、 fsynr=0x7f0011、 cbfrsynra=0x1c90、cb=11 arm-smmu 15000000.iommu：FSR = 00000402 [Format=2 TF]、SID=0x1c90 arm-smmu 150000000.iommu：FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1] 對可編程獨立輔助 RX 的核心上的非 SPH 幀啟用分散收集緩衝區 （GMAC4/XGMAC）：在 stmmac_init_rx_buffers（） 和 stmmac_rx_refill（） 中分配 buffer2 並將其標記為有效，並在緩衝區長度計算中考慮它。舊版核心沒有set_sec_addr操作，因此它們會停用 buffer2。由於 buffer2 會在頁面位移 0 處傳遞給 DMA，因此頁面集區同步處理視窗會加寬，以涵蓋每個模式中的兩個緩衝區：位移設定為 0，max_len 設定為 dma_buf_sz + stmmac_rx_offset（）。FCS 可以跨越 buffer1/buffer2 邊界和描述元邊界，因此現在使用 pskb_trim（） 而不是從單一緩衝區從組裝框架的尾部剝離它，從而避免了使緩衝區溢位 1..3 位元組的框架出現無符號的下溢。對於單一緩衝區框架，XDP 程式不得看到 FCS，因此會在程式執行之前從 XDP 緩衝區中移除它。原生XDP目前僅支援單一緩衝區（線性）框架。MAC 接受的過大幀（啟用巨型）是通過 buffer2 接收的;XDP 程式僅看到 buffer1，因此在 TX/REDIRECT 判定時，幀會被轉送截斷。XDP多緩衝區支援以處理此案例已規劃為後續行動。AF_XDP零拷貝 RX 不在此變更中涵蓋：
    ZC 佇列仍會在 DMA 位址 0 處對 buffer2 進行程式設計 （且 XGMAC 沒有 buffer2 有效位元），因此過大的框架溢位 buffer1 仍可觸發相同的 SMMU 轉譯錯誤。處理計劃作為後續行動。（CVE-2026-98803）

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

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

  - net:stmmac:rx スキャッターギャザーサポートを修正します 受信したフレームが dma_buf_sz より大きい場合、DMA はそれを複数の RX 記述子に分散させます(rx スキャッターギャザー)。セカンダリ RX バッファ(sec_page)は、スプリットヘッダー(SPH)がアクティブな場合にのみ割り当てられ、プログラムされたため、通常のフレームでは、buffer2 は有効なマッピングによって割り当てられず、支援もされていませんでした。着信フレームが buffer1 をオーバーフローするとすぐに、DMA はオーバーフローをマッピングされていないセカンダリバッファアドレスに書き込み、IOMMU ベースのプラットフォームで SMMU 変換違反を発生させました:arm-smmu 15000000.iommu:処理されないコンテキスト違反: fsr=0x402、 iova=0x00000000、 fsynr=0x7f0011、 cbfrsynra=0x1c90、cb=11 arm-smmu 15000000.iommu:FSR = 00000402 [Format=2 TF]、SID=0x1c90 arm-smmu 15000000.iommu: FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1] 独立したセカンダリ RX をプログラムできるコアで、非 SPH フレームに対してスキャッタギャザーを有効化しますbuffer(GMAC4/XGMAC):buffer2 を stmmac_init_rx_buffers() および stmmac_rx_refill() で有効として割り当ててマークし、バッファの長さの計算でそれを考慮します。レガシーコアにはset_sec_addr操作がないため、buffer2 は無効のまま維持されます。バッファ 2 はページオフセット 0 で DMA に渡されるため、ページプール同期ウィンドウは、すべてのモードで両方のバッファをカバーするように広げられます。オフセットは 0 に、max_len は dma_buf_sz + stmmac_rx_offset() に設定されます。FCS は、buffer1/buffer2 の境界と記述子の境界にまたがることができるため、現在は、単一のバッファからではなく、pskb_trim() を使用してアセンブルされたフレームの末尾から取り除かれ、バッファを 1..3 バイトオーバーフローするフレームに対する符号なしアンダーフローを回避します。単一バッファ・フレームの場合、XDP プログラムは FCS を認識してはならないため、プログラムの実行前に XDP バッファから削除されます。ネイティブXDPは現在、シングルバッファ(リニア)フレームのみをサポートしています。MAC が受け入れるオーバーサイズのフレーム(ジャンボ有効)は、buffer2 を介して受信されます。XDPプログラムはbuffer1のみを参照するため、TX/REDIRECT判定ではフレームは切り捨てられて転送されます。このケースを処理するためのXDPマルチバッファのサポートは、フォローアップとして計画されています。AF_XDPゼロコピー RX は、この変更の対象外です:
    ZC キューは、依然として DMA アドレス 0 で buffer2 をプログラムしているため(かつ、XGMAC には buffer2-valid ビットがありません)、オーバーフローする buffer1 がサイズが大きすぎると、依然として同じ SMMU 変換違反が発生する可能性があります。処理はフォローアップとして計画されています。(CVE-2026-98803)

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

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

  - net: stmmac: fix rx Scatter-Gather support When a received frame is larger than dma_buf_sz, the DMA     scatters it across multiple RX descriptors (rx Scatter-Gather). The secondary RX buffer (sec_page) was     only allocated and programmed when split-header (SPH) was active, so for regular frames buffer2 was     neither allocated nor backed by a valid mapping. As soon as an incoming frame overflowed buffer1, the DMA     wrote the overflow into the unmapped secondary-buffer address, triggering an SMMU translation fault on     IOMMU-based platforms: arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000,     fsynr=0x7f0011, cbfrsynra=0x1c90, cb=11 arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x1c90     arm-smmu 15000000.iommu: FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1] Enable scatter-gather for non-SPH     frames on cores that can program an independent secondary RX buffer (GMAC4/XGMAC): allocate and mark     buffer2 as valid in stmmac_init_rx_buffers() and stmmac_rx_refill(), and account for it in the buffer     length computation. Legacy cores have no set_sec_addr op, so they keep buffer2 disabled. Since buffer2 is     handed to the DMA at page offset 0, the page pool sync window is widened to cover both buffers in every     mode: offset is set to 0 and max_len to dma_buf_sz + stmmac_rx_offset(). The FCS can straddle the     buffer1/buffer2 boundary and a descriptor boundary, so it is now stripped from the tail of the assembled     frame with pskb_trim() instead of from a single buffer, avoiding an unsigned underflow for frames that     overflow a buffer by 1..3 bytes. For single-buffer frames the XDP program must not see the FCS, so it is     removed from the XDP buffer before the program runs. Native XDP currently only supports single-buffer     (linear) frames. An oversized frame accepted by the MAC (jumbo enabled) is received via buffer2; the XDP     program only sees buffer1, so on a TX/REDIRECT verdict the frame is forwarded truncated. XDP multi-buffer     support to handle this case is planned as a follow-up. AF_XDP zero-copy RX is not covered by this change:
    a ZC queue still programs buffer2 at DMA address 0 (and XGMAC has no buffer2-valid bit), so an oversized     frame overflowing buffer1 can still trigger the same SMMU translation fault. Handling is planned as a     follow-up. (CVE-2026-98803)

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

ID	Name	Product	Family	Published	Updated	Severity
367162	Linux Distros 未修补的漏洞：CVE-2026-98803	Nessus	Misc.	10/18/2026	10/21/2026	high
367162	Linux Distros 未修補弱點：CVE-2026-98803	Nessus	Misc.	10/18/2026	10/21/2026	high
367162	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98803	Nessus	Misc.	10/18/2026	10/21/2026	high
367162	Linux Distros Unpatched Vulnerability : CVE-2026-98803	Nessus	Misc.	10/18/2026	10/21/2026	high

Detections

Analytics

Plugins Search

high

high

high

high