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

  - bnxt_en：修复填充小数据包的 DMA 映射长度 Stefan Fleischmann 报告 在 VLAN/macvlan 接口上传输数据包时，NetXtreme-E NIC 上 BCM57412 存在 Intel IOMMU DMA 读取错误： DMAR： [DMA 读取NO_PASID] 请求设备 [18:00.0] 错误地址 0xfc499000 [错误原因 0x06] 未设置 PTE 读取访问权限 bnxt_en 0000：18：00.0 eno1np0： 放弃消息 {0xb4 0x41a} len： 0 由于固件状态：0x2000001 ...
    NETDEV 监视程序：eno1np0 （bnxt_en）：传输队列 0 超时 错误地址 （0xfc499000） 位于恰好 4KB 页面边界上，指向 DMA 读取缓冲区溢出。在 bnxt_start_xmit（） 中，填充小于 BNXT_MIN_PKT_SIZE（52 字节）的数据包，例如 42 字节未标记的 ARP 帧：if （length < BNXT_MIN_PKT_SIZE） { pad = BNXT_MIN_PKT_SIZE - length; if （skb_pad（skb， pad）） goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; } mapping = dma_map_single（&pdev->dev， skb->data、len、DMA_TO_DEVICE）;...
    dma_unmap_len_set（tx_buf， len， len）;但是，“len”在 skb_headlen（skb） 之前初始化（例如 42 字节），并且在填充后保持不调整。因此，dma_map_single（） 和 dma_unmap_len_set（） 仅映射和跟踪 42 个字节。随后，使用填充长度对硬件 TX 缓冲区描述符进行编程：
    txbd->tx_bd_len_flags_type = cpu_to_le32（（（len + pad） << TX_BD_LEN_SHIFT） | flags |TX_BD_FLAGS_PACKET_END）;因此，指示 NIC DMA 引擎从仅 42 字节为 DMA 映射的区域读取 52 字节。如果 skb->data 在 4KB 页面的边界附近（在下一页的“pad”字节内）结束，则硬件 DMA 读取会溢出到未映射的相邻页面，从而触发 IOMMU 错误。
    此问题在提交 447cbe95ebb9（vlan：修复切换 HW VLAN 卸载时的skb_under_panic和争用）之后暴露，因为预留额外的 VLAN 余量会将LL_RESERVED_SPACE从 48 个字节舍入到 64 个字节，从而改变了 skb->data 偏移并可能导致小帧直接靠在页面边界上。在对 skb_shinfo（skb）->nr_frags 进行采样之前，通过在 bnxt_start_xmit（） 中使用 skb_put_padto（skb， BNXT_MIN_PKT_SIZE） 修复此问题，因为填充可能会线性化 skb。这可确保 skb->len 和 skb_headlen（skb） 反映填充的大小，使 dma_map_single（） 映射完整缓冲区，且描述符长度一致。
    这还会删除临时“pad”变量和掩码逻辑。填充在 SW USO 分支之后完成，否则 bnxt_sw_udp_gso_xmit（） 会将该填充视为 UDP 负载并在额外的段中发送。请注意，SW USO 段仍未填充：使用 IPv4 时，携带少于 10 字节 UDP 负载（小gso_size或最后一段短）的段将作为短于 BNXT_MIN_PKT_SIZE 的帧发送。这是单独的问题，留待后续修补程序。（CVE-2026-99081）

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

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

  - bnxt_en：修正填充小封包的 DMA 對應長度 Stefan Fleischmann 報告了在 VLAN/macvlan 介面上傳輸封包時，NetXtreme-E NIC 上的 BCM57412 Intel IOMMU DMA 讀取錯誤： DMAR： [DMA 讀取NO_PASID] 請求裝置 [18:00.0] 錯誤 addr 0xfc499000 [錯誤原因 0x06] 未設定 PTE 讀取存取權 bnxt_en 0000：18：00.0 eno1np0： 放棄訊息 {0xb4 0x41a} len： 0 由於韌體狀態：0x2000001 ...
    NETDEV 看門程式：eno1np0 （bnxt_en）：傳輸佇列 0 逾時 錯誤位址 （0xfc499000） 位於確切的 4KB 頁面邊界上，指向 DMA 讀取緩衝區溢位。在 bnxt_start_xmit（） 中，小於 BNXT_MIN_PKT_SIZE （52 位元組） 的封包 （例如 42 位元組未標記的 ARP 框架） 會被填充： if （length < BNXT_MIN_PKT_SIZE） { pad = BNXT_MIN_PKT_SIZE - length; if （skb_pad（skb， pad）） goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; } 映射 = dma_map_single（&pdev->dev， skb->data， len， DMA_TO_DEVICE）;...
    dma_unmap_len_set（tx_buf， len， len）;然而，'len' 較早初始化為 skb_headlen（skb） （例如 42 位元組），並且在填充後保持不變。因此，dma_map_single（） 和 dma_unmap_len_set（） 僅映射和追蹤 42 個位元組。稍後，硬體 TX 緩衝區描述元會使用填充長度進行程式設計：
    txbd->tx_bd_len_flags_type = cpu_to_le32（（（len + pad） << TX_BD_LEN_SHIFT） | 旗標 |TX_BD_FLAGS_PACKET_END）;因此，NIC DMA 引擎會被指示從只有 42 個位元組被 DMA 對應的區域讀取 52 個位元組。如果 skb->data 在 4KB 頁面的邊界附近結束 （在下一頁的「填充」位元組內），則硬體 DMA 讀取會溢位到未對應的相鄰頁面，從而觸發 IOMMU 錯誤。
    此問題在提交 447cbe95ebb9 （vlan：修正切換硬體 VLAN 卸載時的skb_under_panic和爭用） 之後暴露，因為保留額外的 VLAN 餘量會將LL_RESERVED_SPACE從 48 位元組四捨五入到 64 位元組，從而移動 skb->data 位移，並可能導致小框架直接落在頁面邊界上。在取樣 skb_shinfo（skb）->nr_frags之前，在 bnxt_start_xmit（） 中使用 skb_put_padto（skb， BNXT_MIN_PKT_SIZE） 來修正此問題，因為填充可能會使 skb 線性化。這可確保 skb->len 和 skb_headlen（skb） 反映填充大小，以便 dma_map_single（） 映射完整緩衝區，且描述元長度一致。
    這也移除了臨時的「pad」變數和遮罩邏輯。填充在 SW USO 分支之後完成，否則 bnxt_sw_udp_gso_xmit（） 會將填充視為 UDP 負載並將其分到額外的區段中發送。請注意，SW USO 區段仍然未填充：使用 IPv4 時，攜帶少於 10 位元組 UDP 負載 （小gso_size或短最後一個區段） 的區段會以短於 BNXT_MIN_PKT_SIZE 的幀的形式傳送。這是一個單獨的問題，留給後續補丁。（CVE-2026-99081）

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

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

  - bnxt_en:パディングされた小さなパケットに対する DMA マッピング長を修正します Stefan Fleischmann 氏は、Intel IOMMU DMA が、VLAN/macvlan インターフェイスでパケットを送信する際に、 BCM57412 NetXtreme-E NIC で読み取り障害があることを報告しました: DMAR: [DMA 読み取り NO_PASID] リクエストデバイス [18:00.0] 障害アドレス 0xfc499000 [障害理由 0x06] PTE 読み取りアクセスが設定されていません bnxt_en 0000:18:00.0 eno1np0: msg {0xb4 0x41a} len を放棄しています: ファームウェアのステータスによる0:0x2000001 ...
    NETDEV WATCHDOG:eno1np0(bnxt_en):送信キュー 0 がタイムアウトしました 障害アドレス(0xfc499000)は正確な 4KB ページ境界上にあり、DMA 読み取りバッファオーバーランを示しています。bnxt_start_xmit() では、42 バイトのタグなし ARP フレームなどの、BNXT_MIN_PKT_SIZE(52 バイト)未満のパケットがパディングされます:if (length < BNXT_MIN_PKT_SIZE) { pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; } mapping = dma_map_single(&pdev->dev, skb->data、len、DMA_TO_DEVICE);...
    dma_unmap_len_set(tx_buf、len、len);ただし、「len」は skb_headlen(skb) より前(例:42 バイト)に初期化され、パディング後は調整されません。その結果、dma_map_single() と dma_unmap_len_set() は 42 バイトのみをマッピングして追跡します。後で、ハードウェア TX バッファ記述子は、パディングの長さでプログラムされます。
    txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | フラグ |TX_BD_FLAGS_PACKET_END);このため、NIC DMA エンジンは、DMA がマッピングされたのは 42 バイトのみである領域から 52 バイトを読み取るように指示されます。skb->dataが4KBページの境界近く(次のページの「pad」バイト内)で終了する場合、ハードウェアDMA読み取りがマップされていない隣接ページにオーバーランし、IOMMU障害をトリガーします。
    この問題は、コミット 447cbe95ebb9(vlan:HW VLAN オフロードを切り替えるときのskb_under_panicと競合を修正)後に明らかになりました。これは、余分な VLAN ヘッドルームを予約すると、LL_RESERVED_SPACEが 48 バイトから 64 バイトに丸められ、skb->data オフセットがシフトされ、小さなフレームがページ境界に対して右に着地する可能性があるためです。パディングが skb を線形化する可能性があるため、skb_shinfo(skb)->nr_frags がサンプリングされる前に、bnxt_start_xmit() で skb_put_padto(skb, BNXT_MIN_PKT_SIZE) を使用してこれを修正します。これにより、skb->len と skb_headlen(skb) がパディングサイズを反映し、dma_map_single() がバッファ全体をマッピングし、記述子の長さに一本が一致するようにします。
    これにより、一時的な「pad」変数およびマスキングロジックも削除されます。パディングは SW USO ブランチの後に行われます。そうでなければ、bnxt_sw_udp_gso_xmit() はパディングを UDP ペイロードとみなし、それを余分なセグメントに送信します。注意:SW USO セグメントはまだパディングされていません:IPv4 では、10 バイト未満の UDP ペイロードを運ぶセグメント(小さなgso_size、または最後の短いセグメント)は、BNXT_MIN_PKT_SIZEより短いフレームとして送信されます。これは別の問題であり、フォローアップパッチに残されています。(CVE-2026-99081)

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

An update of the linux package has been released.

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

  - bnxt_en: fix DMA mapping length for padded small packets Stefan Fleischmann reported Intel IOMMU DMA Read     faults on BCM57412 NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces: DMAR: [DMA Read     NO_PASID] Request device [18:00.0] fault addr 0xfc499000 [fault reason 0x06] PTE Read access is not set     bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001 ...
    NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out The fault address (0xfc499000) is on an     exact 4KB page boundary, pointing to a DMA read buffer overrun. In bnxt_start_xmit(), packets smaller than     BNXT_MIN_PKT_SIZE (52 bytes), such as 42-byte untagged ARP frames, are padded: if (length <     BNXT_MIN_PKT_SIZE) { pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length     = BNXT_MIN_PKT_SIZE; } mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE); ...
    dma_unmap_len_set(tx_buf, len, len); However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42     bytes) and is left unadjusted after padding. Consequently, dma_map_single() and dma_unmap_len_set() map     and track only 42 bytes. Later, the hardware TX buffer descriptor is programmed with the padded length:
    txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags |     TX_BD_FLAGS_PACKET_END); The NIC DMA engine is thus instructed to read 52 bytes from a region where only     42 bytes were DMA-mapped. If skb->data ends near the boundary of a 4KB page (within 'pad' bytes of the     next page), the hardware DMA read overruns into the unmapped adjacent page, triggering an IOMMU fault.
    This issue was exposed after commit 447cbe95ebb9 (vlan: fix skb_under_panic and races when toggling HW     VLAN offload) because reserving extra VLAN headroom rounded LL_RESERVED_SPACE from 48 up to 64 bytes,     shifting skb->data offsets and potentially causing small frames to land right against page boundaries. Fix     this by using skb_put_padto(skb, BNXT_MIN_PKT_SIZE) in bnxt_start_xmit(), before skb_shinfo(skb)->nr_frags     is sampled, because padding might linearize the skb. This ensures skb->len and skb_headlen(skb) reflect     the padded size so that dma_map_single() maps the full buffer and the descriptor length is consistent.
    This also removes the temporary 'pad' variable and masking logic. The padding is done after the SW USO     branch, otherwise bnxt_sw_udp_gso_xmit() would account the padding as UDP payload and send it in extra     segments. Note that SW USO segments are still not padded: with IPv4, a segment carrying less than 10 bytes     of UDP payload (small gso_size, or a short last segment) is sent as a frame shorter than     BNXT_MIN_PKT_SIZE. This is a separate issue, left for a followup patch. (CVE-2026-99081)

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

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1793786843 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: qmi_encdec: Restrict string     length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null     terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of     bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

  - In the Linux kernel, the following vulnerability has been resolved: rv: Use strings in da monitors     tracepoints Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN:
    global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr     ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0     ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200     trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0     This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata     definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g.
    the next automaton's data in this case). The error is harmless as, while printing the string, we stop at     the null terminator, but it should still be fixed. Use the __string facilities while defining the     tracepoints to avoid reading out of bound memory. (CVE-2025-38636)

  - In the Linux kernel, the following vulnerability has been resolved: perf: arm_spe: Prevent overflow in     PERF_IDX2OFF() Cast nr_pages to unsigned long to avoid overflow when handling large AUX buffer sizes (>= 2     GiB). (CVE-2025-40081)

  - In the Linux kernel, the following vulnerability has been resolved: arch_topology: Fix incorrect error     check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in     topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic     uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to     potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation,     PTR_ERR_OR_ZERO(ptr) returns: The error code within @ptr if it is an error pointer; 0 otherwise. This     means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore     !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing     clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk)     which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().
    (CVE-2025-40346)

  - In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Add support for     Van Gogh SoC The ROG Xbox Ally (non-X) SoC features a similar architecture to the Steam Deck. While the     Steam Deck supports S3 (s2idle causes a crash), this support was dropped by the Xbox Ally which only S0ix     suspend. Since the handler is missing here, this causes the device to not suspend and the AMD GPU driver     to crash while trying to resume afterwards due to a power hang. (CVE-2025-68334)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
371489	Linux Distros 未修补的漏洞：CVE-2026-99081	Nessus	Misc.	2026/10/23	2026/11/11	high
371489	Linux Distros 未修補弱點：CVE-2026-99081	Nessus	Misc.	2026/10/23	2026/11/11	high
371489	Linux Distros のパッチ未適用の脆弱性: CVE-2026-99081	Nessus	Misc.	2026/10/23	2026/11/11	high
379844	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2026-139)	Nessus	Amazon Linux Local Security Checks	2026/11/12	2026/11/12	critical
375086	Photon OS 5.0: Linux PHSA-2026-5.0-92-1044	Nessus	PhotonOS Local Security Checks	2026/11/2	2026/11/2	critical
371489	Linux Distros Unpatched Vulnerability : CVE-2026-99081	Nessus	Misc.	2026/10/23	2026/11/11	high
376201	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1793786843)	Nessus	Alma Linux Local Security Checks	2026/11/5	2026/11/5	high

检测

插件搜索

high

high

high

critical

critical

high

high