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

  - net：gso：限制递归 IP-in-IP 分段 IP-in-IP GSO 可针对每个嵌套 IP 标头重新输入 inet_gso_segment（） 或 ipv6_gso_segment（）。encap_level跟踪标头字节而非回调深度，因此深链可耗尽内核堆栈。使 inet_gso_segment（） 可堆叠引入了不受限制的 IPv4 嵌套;IPIP GSO/TSO 稍后使该路径可访问。IPv6 可堆叠路径是单独引入的，并使用相同的防护。对 skb_gso_cb 中的 IPv4 和 IPv6 GSO 处理程序条目进行计数，在每个顶级 GSO 操作中初始化一次，并跨 GRE/UDP 上下文更改保留。同时对这两个处理程序使用现有IP_TUNNEL_RECURSION_LIMIT。前五个条目传递，第六个条目返回 -EINVAL，然后再调度另一个 GSO 回调。（CVE-2026-98853）

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

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

  - net： gso：限制遞迴 IP-in-IP 分段 IP-in-IP GSO 可以針對每個巢狀 IP 標頭重新輸入 inet_gso_segment（） 或 ipv6_gso_segment（）。encap_level追蹤的是標頭位元組，而不是回呼深度，因此深鏈可能會耗盡核心堆疊。使 inet_gso_segment（） 可堆疊引入了無限的 IPv4 巢狀結構;IPIP GSO/TSO 後來使該路徑可連線。IPv6 可堆疊路徑是單獨引入的，並使用相同的防護。計算 skb_gso_cb 中的 IPv4 和 IPv6 GSO 處理常式項目，每個頂層 GSO 作業初始化一次，並在 GRE/UDP 上下文變更中保留。針對這兩個處理常式使用現有的IP_TUNNEL_RECURSION_LIMIT。前五個項目通過，第六個項目傳回 -EINVAL，然後再分派另一個 GSO 回呼。（CVE-2026-98853）

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

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

  - net:gso:再帰的な IP-in-IP セグメンテーションを制限します IP-in-IP GSO は、ネスト化されたそれぞれの IP ヘッダーに対して inet_gso_segment() または ipv6_gso_segment() を再入力する可能性があります。encap_levelは、コールバックの深さではなくヘッダーバイトを追跡するため、ディープチェーンがカーネルスタックを枯渇させる可能性があります。inet_gso_segment()をスタック可能にすると、無制限のIPv4ネスト化が導入されました。後に、IPIP GSO/TSO がパスを到達可能にしました。IPv6 スタック可能パスは別々に導入され、同じガードを使用します。skb_gso_cb の IPv4 および IPv6 GSO ハンドラーエントリをカウントし、トップレベルの GSO 操作ごとに一度だけ初期化され、GRE/UDP コンテキスト変更後も保持されます。両方のハンドラーに既存のIP_TUNNEL_RECURSION_LIMITを使用します。最初の 5 つのエントリはパスし、6 番目のエントリは別の GSO コールバックをディスパッチする前に -EINVAL を返します。(CVE-2026-98853)

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

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

  - net: gso: limit recursive IP-in-IP segmentation IP-in-IP GSO can re-enter inet_gso_segment() or     ipv6_gso_segment() for each nested IP header. encap_level tracks header bytes, not callback depth, so a     deep chain can exhaust the kernel stack. Making inet_gso_segment() stackable introduced unbounded IPv4     nesting; IPIP GSO/TSO later made the path reachable. The IPv6 stackable path was introduced separately and     uses the same guard. Count IPv4 and IPv6 GSO handler entries in skb_gso_cb, initialized once per top-level     GSO operation and preserved across GRE/UDP context changes. Use the existing IP_TUNNEL_RECURSION_LIMIT for     both handlers. The first five entries pass, and the sixth returns -EINVAL before dispatching another GSO     callback. (CVE-2026-98853)

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

The remote Ubuntu 26.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-9018-1 advisory.

    Several security issues were discovered in the Linux kernel. An attacker could possibly use these to     compromise the system. This update corrects flaws in the following subsystems:

    - Network file systems library;

    - Stream parser;

    - ARM64 architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - S390 architecture;

    - User-Mode Linux (UML);

    - x86 architecture;

    - Block layer subsystem;

    - Android drivers;

    - Bluetooth drivers;

    - TPM device driver;

    - DPLL subsystem;

    - EDAC drivers;

    - GPIO subsystem;

    - GPU drivers;

    - HID subsystem;

    - IIO subsystem;

    - IIO ADC drivers;

    - InfiniBand drivers;

    - Input Device (Miscellaneous) drivers;

    - Multiple devices driver;

    - MemoryStick subsystem;

    - MMC subsystem;

    - MTD block device drivers;

    - Network drivers;

    - Ethernet bonding driver;

    - Mellanox network drivers;

    - STMicroelectronics network drivers;

    - Ethernet team driver;

    - MediaTek network drivers;

    - NVME drivers;

    - Device tree and open firmware driver;

    - Power sequencing drivers;

    - Voltage and Current Regulator drivers;

    - Real Time Clock drivers;

    - SCSI subsystem;

    - Greybus lights staging drivers;

    - Trusted Execution Environment drivers;

    - Thunderbolt and USB4 drivers;

    - TTY drivers;

    - Cadence USB3 driver;

    - USB Device Class drivers;

    - USB core drivers;

    - DesignWare USB2 driver;

    - DesignWare USB3 driver;

    - USB Gadget drivers;

    - USB Serial drivers;

    - USB Mass Storage drivers;

    - USB Type-C support driver;

    - USB Type-C Port Controller Manager driver;

    - TI TPS6598x USB Power Delivery controller driver;

    - USB Type-C Connector System Software Interface driver;

    - Amazon Nitro Enclaves driver;

    - Virtual machine generation ID driver;

    - BTRFS file system;

    - File systems infrastructure;

    - SMB network file system;

    - XFS file system;

    - BPF subsystem;

    - io_uring subsystem;

    - Netfilter;

    - Namespaces infrastructure;

    - Networking core;

    - Networking subsytem;

    - Virtio network driver;

    - Bluetooth subsystem;

    - IPv4 networking;

    - Network traffic control;

    - Audit subsystem;

    - Control group (cgroup);

    - Perf events;

    - Kernel fork() syscall;

    - Kernel futex primitives;

    - KProbes tracing;

    - Kexec HandOver (KHO);

    - Kernel module support;

    - Tracing infrastructure;

    - Workqueue subsystem;

    - Memory management;

    - Ethernet bridge;

    - Devlink API;

    - IPv6 networking;

    - MAC80211 subsystem;

    - Management Component Transport Protocol (MCTP);

    - Open vSwitch;

    - Packet sockets;

    - SCTP protocol;

    - SMC sockets;

    - TIPC protocol;

    - VMware vSockets driver;

    - Wireless networking;

    - XFRM subsystem;

    - Drivers core;

    - Key management;

    - SELinux security module;

    - ALSA framework;

    - Creative Sound Blaster X-Fi driver;

    - Analog Devices audio codecs;

    - Maxim audio codecs;

    - Realtek audio codecs;

    - QCOM ASoC drivers;

    - Samsung ASoC drivers;

    - SoundWire (SDCA) ASoC drivers;

    - USB sound devices; (CVE-2026-68305, CVE-2026-72404, CVE-2026-72497, CVE-2026-74527, CVE-2026-74568,     CVE-2026-89568, CVE-2026-89764, CVE-2026-89907, CVE-2026-90144, CVE-2026-90155, CVE-2026-90162,     CVE-2026-90167, CVE-2026-90317, CVE-2026-93175, CVE-2026-98038, CVE-2026-98375, CVE-2026-98432,     CVE-2026-98655, CVE-2026-98656, CVE-2026-98657, CVE-2026-98658, CVE-2026-98659, CVE-2026-98660,     CVE-2026-98661, CVE-2026-98662, CVE-2026-98663, CVE-2026-98664, CVE-2026-98665, CVE-2026-98666,     CVE-2026-98667, CVE-2026-98668, CVE-2026-98669, CVE-2026-98670, CVE-2026-98671, CVE-2026-98672,     CVE-2026-98673, CVE-2026-98674, CVE-2026-98675, CVE-2026-98676, CVE-2026-98677, CVE-2026-98678,     CVE-2026-98679, CVE-2026-98680, CVE-2026-98681, CVE-2026-98682, CVE-2026-98683, CVE-2026-98684,     CVE-2026-98685, CVE-2026-98686, CVE-2026-98687, CVE-2026-98689, CVE-2026-98690, CVE-2026-98691,     CVE-2026-98692, CVE-2026-98693, CVE-2026-98694, CVE-2026-98695, CVE-2026-98696, CVE-2026-98697,     CVE-2026-98698, CVE-2026-98699, CVE-2026-98700, CVE-2026-98701, CVE-2026-98702, CVE-2026-98703,     CVE-2026-98704, CVE-2026-98705, CVE-2026-98706, CVE-2026-98707, CVE-2026-98708, CVE-2026-98709,     CVE-2026-98710, CVE-2026-98711, CVE-2026-98712, CVE-2026-98713, CVE-2026-98714, CVE-2026-98715,     CVE-2026-98716, CVE-2026-98717, CVE-2026-98718, CVE-2026-98719, CVE-2026-98720, CVE-2026-98721,     CVE-2026-98722, CVE-2026-98723, CVE-2026-98724, CVE-2026-98725, CVE-2026-98726, CVE-2026-98727,     CVE-2026-98728, CVE-2026-98729, CVE-2026-98730, CVE-2026-98731, CVE-2026-98732, CVE-2026-98733,     CVE-2026-98734, CVE-2026-98735, CVE-2026-98736, CVE-2026-98737, CVE-2026-98738, CVE-2026-98739,     CVE-2026-98740, CVE-2026-98741, CVE-2026-98742, CVE-2026-98743, CVE-2026-98744, CVE-2026-98745,     CVE-2026-98746, CVE-2026-98747, CVE-2026-98748, CVE-2026-98749, CVE-2026-98750, CVE-2026-98751,     CVE-2026-98752, CVE-2026-98753, CVE-2026-98754, CVE-2026-98755, CVE-2026-98756, CVE-2026-98757,     CVE-2026-98758, CVE-2026-98759, CVE-2026-98760, CVE-2026-98761, CVE-2026-98762, CVE-2026-98763,     CVE-2026-98764, CVE-2026-98765, CVE-2026-98766, CVE-2026-98767, CVE-2026-98768, CVE-2026-98769,     CVE-2026-98770, CVE-2026-98771, CVE-2026-98772, CVE-2026-98773, CVE-2026-98774, CVE-2026-98775,     CVE-2026-98776, CVE-2026-98777, CVE-2026-98778, CVE-2026-98779, CVE-2026-98780, CVE-2026-98781,     CVE-2026-98782, CVE-2026-98783, CVE-2026-98784, CVE-2026-98785, CVE-2026-98786, CVE-2026-98788,     CVE-2026-98789, CVE-2026-98790, CVE-2026-98791, CVE-2026-98792, CVE-2026-98793, CVE-2026-98794,     CVE-2026-98795, CVE-2026-98796, CVE-2026-98797, CVE-2026-98798, CVE-2026-98799, CVE-2026-98800,     CVE-2026-98801, CVE-2026-98802, CVE-2026-98803, CVE-2026-98804, CVE-2026-98805, CVE-2026-98806,     CVE-2026-98807, CVE-2026-98808, CVE-2026-98809, CVE-2026-98810, CVE-2026-98811, CVE-2026-98812,     CVE-2026-98813, CVE-2026-98814, CVE-2026-98816, CVE-2026-98817, CVE-2026-98818, CVE-2026-98819,     CVE-2026-98820, CVE-2026-98821, CVE-2026-98822, CVE-2026-98823, CVE-2026-98824, CVE-2026-98825,     CVE-2026-98826, CVE-2026-98827, CVE-2026-98828, CVE-2026-98829, CVE-2026-98830, CVE-2026-98831,     CVE-2026-98833, CVE-2026-98834, CVE-2026-98835, CVE-2026-98836, CVE-2026-98837, CVE-2026-98838,     CVE-2026-98839, CVE-2026-98840, CVE-2026-98841, CVE-2026-98842, CVE-2026-98843, CVE-2026-98844,     CVE-2026-98845, CVE-2026-98846, CVE-2026-98847, CVE-2026-98848, CVE-2026-98849, CVE-2026-98850,     CVE-2026-98851, CVE-2026-98852, CVE-2026-98853, CVE-2026-98854, CVE-2026-98855, CVE-2026-98856,     CVE-2026-98857, CVE-2026-98858, CVE-2026-98859, CVE-2026-98860, CVE-2026-98861, CVE-2026-98862,     CVE-2026-98863, CVE-2026-98931, CVE-2026-98932, CVE-2026-98933, CVE-2026-98934, CVE-2026-98935,     CVE-2026-98936, CVE-2026-98937, CVE-2026-98939, CVE-2026-98940, CVE-2026-98944, CVE-2026-98945,     CVE-2026-98946, CVE-2026-98947, CVE-2026-98948, CVE-2026-98949, CVE-2026-98950, CVE-2026-98951,     CVE-2026-98952, CVE-2026-98953, CVE-2026-98954, CVE-2026-98955, CVE-2026-98956, CVE-2026-98957,     CVE-2026-98958, CVE-2026-98959, CVE-2026-98960, CVE-2026-98961, CVE-2026-98962, CVE-2026-98963,     CVE-2026-98964, CVE-2026-98965, CVE-2026-98966, CVE-2026-98967, CVE-2026-98968, CVE-2026-98969,     CVE-2026-98970, CVE-2026-98971, CVE-2026-98972, CVE-2026-98973, CVE-2026-98974, CVE-2026-98975,     CVE-2026-98977, CVE-2026-98978, CVE-2026-98979, CVE-2026-98980, CVE-2026-98981, CVE-2026-98982,     CVE-2026-98983, CVE-2026-98984, CVE-2026-98985, CVE-2026-98986, CVE-2026-98987, CVE-2026-98988,     CVE-2026-98989, CVE-2026-98990, CVE-2026-98991, CVE-2026-98992, CVE-2026-98993, CVE-2026-98994,     CVE-2026-98995, CVE-2026-98996, CVE-2026-98997, CVE-2026-98999, CVE-2026-99000, CVE-2026-99001,     CVE-2026-99002, CVE-2026-99003, CVE-2026-99004, CVE-2026-99005, CVE-2026-99006, CVE-2026-99007,     CVE-2026-99008, CVE-2026-99009, CVE-2026-99010, CVE-2026-99011, CVE-2026-99012, CVE-2026-99013,     CVE-2026-99014, CVE-2026-99015, CVE-2026-99016, CVE-2026-99017, CVE-2026-99018, CVE-2026-99019,     CVE-2026-99020, CVE-2026-99021, CVE-2026-99022, CVE-2026-99023, CVE-2026-99024, CVE-2026-99025,     CVE-2026-99026, CVE-2026-99027, CVE-2026-99028, CVE-2026-99029, CVE-2026-99030, CVE-2026-99031,     CVE-2026-99032, CVE-2026-99033, CVE-2026-99034, CVE-2026-99035, CVE-2026-99036, CVE-2026-99037,     CVE-2026-99038, CVE-2026-99039, CVE-2026-99040, CVE-2026-99041, CVE-2026-99043, CVE-2026-99044,     CVE-2026-99045, CVE-2026-99046, CVE-2026-99047, CVE-2026-99048, CVE-2026-99049, CVE-2026-99050,     CVE-2026-99051, CVE-2026-99052, CVE-2026-99053, CVE-2026-99054, CVE-2026-99055, CVE-2026-99056,     CVE-2026-99057, CVE-2026-99058, CVE-2026-99059, CVE-2026-99060, CVE-2026-99061, CVE-2026-99062,     CVE-2026-99063, CVE-2026-99064, CVE-2026-99065, CVE-2026-99066, CVE-2026-99067, CVE-2026-99068,     CVE-2026-99069, CVE-2026-99070, CVE-2026-99071, CVE-2026-99072, CVE-2026-99073, CVE-2026-99074,     CVE-2026-99075, CVE-2026-99076, CVE-2026-99077, CVE-2026-99078, CVE-2026-99079, CVE-2026-99080,     CVE-2026-99081, CVE-2026-99088, CVE-2026-99089, CVE-2026-99090, CVE-2026-99091, CVE-2026-99092,     CVE-2026-99093, CVE-2026-99094, CVE-2026-99095, CVE-2026-99096, CVE-2026-99097, CVE-2026-99098,     CVE-2026-99099, CVE-2026-99999)

Tenable has extracted the preceding description block directly from the Ubuntu 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 Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1794654433 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: add HE 6 GHz     capability in the scan elems len The HE 6 GHz Band Capability element is in the probe request for every     band if 6 GHz is supported, so add the size to scan_ies_len. Otherwise, building probe request elements     can fail, triggering the WARN_ON in __ieee80211_start_scan(). (CVE-2026-98328)

  - In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-     grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also     crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb     head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is     that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at     least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is     adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start =     page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression     subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the     previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb     is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the     right page. In either case, the corrupted reference count can lead to the page being prematurely recycled     while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this     would result in a double free. The commit under fixes updated this code to handle the case where the     native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset     field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate     it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to     compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are     two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at     page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is     called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr     was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with     this commit applied causes the test to run successfully to completion. The other rx_skb_func     implementations don't have this issue. (CVE-2026-74269)

  - In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Repost Receive buffers for     malformed replies rpcrdma_wc_receive() decrements the transport's Receive count for every completion     before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement     Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.
    Commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting Receives) moved the     Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into     rpcrdma_reply_handler() so that the responder's credit grant could be parsed before reposting. The bad-     version and short-reply exits never reach that refill: they recycle the rep and return without calling     rpcrdma_post_recvs(). A remote peer can therefore drain the client's posted Receive queue by sending a     sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized     RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue     empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect. Route both     malformed-reply exits through the shared repost tail after recycling the rep, refilling against     buf->rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so     RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would     let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the     congestion window still admits rb_credits RPCs; a burst of valid replies to those RPCs could then overrun     the posted Receives, and because the client connects with rnr_retry_count of zero, a single RNR NAK     terminates the connection. Refilling against rb_credits also restores the target that applied to malformed     replies before commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting     Receives) when rpcrdma_post_recvs() computed it from rb_credits internally. rb_credits is at least one     from connection establishment onward, so the repost path always keeps Receives posted. (CVE-2026-72464)

  - In the Linux kernel, the following vulnerability has been resolved: smb: client: avoid using uninitialized     SIDs in cifs_posix_to_fattr() cifs_posix_to_fattr() ignores the return value of posix_info_parse(). When a     malformed POSIX directory entry is encountered (e.g. invalid SID lengths from an untrusted server),     posix_info_parse() returns -1 without populating the 'parsed' struct. The uninitialized stack memory in     parsed.owner and parsed.group is then passed to sid_to_id(), which processes the garbage bytes and passes     them to request_key() to construct a SID string, potentially leaking kernel stack contents to the     userspace idmap daemon. Fix this by checking the return value and skipping the SID-to-id mapping when     parsing fails. The remaining fattr fields (timestamps, mode, etc.) are populated directly from the 'info'     pointer so they are unaffected. (CVE-2026-97554)

  - In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent     states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO:
    rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8     task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec     mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof     alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in     bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on     PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task     never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a     quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1] (CVE-2026-89753)

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

The CentOS Linux 8.4 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.4:CLSA-2026:1794319150 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Repost Receive buffers for     malformed replies rpcrdma_wc_receive() decrements the transport's Receive count for every completion     before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement     Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.
    Commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting Receives) moved the     Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into     rpcrdma_reply_handler() so that the responder's credit grant could be parsed before reposting. The bad-     version and short-reply exits never reach that refill: they recycle the rep and return without calling     rpcrdma_post_recvs(). A remote peer can therefore drain the client's posted Receive queue by sending a     sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized     RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue     empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect. Route both     malformed-reply exits through the shared repost tail after recycling the rep, refilling against     buf->rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so     RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would     let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the     congestion window still admits rb_credits RPCs; a burst of valid replies to those RPCs could then overrun     the posted Receives, and because the client connects with rnr_retry_count of zero, a single RNR NAK     terminates the connection. Refilling against rb_credits also restores the target that applied to malformed     replies before commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting     Receives) when rpcrdma_post_recvs() computed it from rb_credits internally. rb_credits is at least one     from connection establishment onward, so the repost path always keeps Receives posted. (CVE-2026-72464)

  - In the Linux kernel, the following vulnerability has been resolved: sctp: check RCV_SHUTDOWN after the     sendmsg connect wait sctp_wait_for_connect() drops the socket lock while it sleeps. An out-of-the-blue     ABORT can then be processed from the socket backlog and unlink the association. If a concurrent     shutdown(fd, SHUT_RD) sets RCV_SHUTDOWN, the waiter breaks with err == 0 before checking asoc->base.dead.
    Its final sctp_association_put() can then free the association, leaving sctp_sendmsg_to_asoc() to continue     with a dangling pointer. Check RCV_SHUTDOWN along with the wait error in sctp_sendmsg_to_asoc() before     using the association again. The check only accesses the socket, so it needs no additional association     reference. Return the existing -ESRCH so that sctp_sendmsg() skips freeing a new association that may     already have been destroyed. Keep sctp_wait_for_connect() unchanged to preserve its behavior for the     connect() caller. (CVE-2026-98846)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in     enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user     context. The spinlock protects the backlog queue in this path, but it does not serialize against the     socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3     Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS     1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123     print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597
    __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0     net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60     net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188     tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689
    __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400     sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884     do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431
    __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41     do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e     arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89     d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00     00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX:
    0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f     RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09:
    0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021     R14: 0000000000000000 R15: 00007fff89799c40 </TASK> The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue()     also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued     or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held     spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the     socket is owned by user context. (CVE-2026-72299)

  - In the Linux kernel, the following vulnerability has been resolved: ceph: bound copied dentry name length     in NFS export get_name ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized     buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0,     without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with     dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same     unchecked way. Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a     client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS     mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with
    -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name(). (CVE-2026-89652)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range nseconds in     NFSv3 SETATTR and create ops A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying     an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes     cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC.
    Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which     does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity     (s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via     inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's     ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field     and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS     with bigtime mis-stores the timestamp for the same reason. Validate the client-supplied atime/mtime in the     proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for     SETATTR and describes it as the error for a value the server 'can not store ... in its own     representation'; the client maps it to EINVAL. Checking in the proc handlers, rather than in     nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object     before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-     idempotent request into a namespace change that reports failure. The check is therefore done up front, for     the create operations before the object is created. tv_nsec is a long, so the comparison casts it to     unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate     on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire     nseconds was assigned to a 32-bit long. Only client-supplied times are checked: SET_TO_SERVER_TIME     requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard     simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison,     which is the protocol-correct outcome rather than rejecting the request. (CVE-2026-89666)

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

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.

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

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: add HE 6 GHz     capability in the scan elems len The HE 6 GHz Band Capability element is in the probe request for every     band if 6 GHz is supported, so add the size to scan_ies_len. Otherwise, building probe request elements     can fail, triggering the WARN_ON in __ieee80211_start_scan(). (CVE-2026-98328)

  - In the Linux kernel, the following vulnerability has been resolved: bnxt: fix head underflow on XDP head-     grow The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also     crashes in NIPA). It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb     head: napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size); The problem with this expression is     that in page mode, rx_offset is: bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM; Which evaluates (at     least on x86_64) to 258. The test test_xdp_native_adjst_head_grow_data tests a case where the head is     adjusted by -256. When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start =     page_address(page) + offset). Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression     subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the     previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0). When the skb     is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the     right page. In either case, the corrupted reference count can lead to the page being prematurely recycled     while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this     would result in a double free. The commit under fixes updated this code to handle the case where the     native page size is >= 64k, but it unintentionally broke the head grow case. To fix this, add an offset     field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate     it on allocation and preserve it on reuse. In bnxt_rx_multi_page_skb, use the newly added offset field to     compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve. There are     two cases, the non-adjustment case and the adjustment case. In both cases, the skb is built at     page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is     called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr     was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head. Re-running the failing test with     this commit applied causes the test to run successfully to completion. The other rx_skb_func     implementations don't have this issue. (CVE-2026-74269)

  - In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Repost Receive buffers for     malformed replies rpcrdma_wc_receive() decrements the transport's Receive count for every completion     before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement     Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.
    Commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting Receives) moved the     Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into     rpcrdma_reply_handler() so that the responder's credit grant could be parsed before reposting. The bad-     version and short-reply exits never reach that refill: they recycle the rep and return without calling     rpcrdma_post_recvs(). A remote peer can therefore drain the client's posted Receive queue by sending a     sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized     RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue     empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect. Route both     malformed-reply exits through the shared repost tail after recycling the rep, refilling against     buf->rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so     RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would     let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the     congestion window still admits rb_credits RPCs; a burst of valid replies to those RPCs could then overrun     the posted Receives, and because the client connects with rnr_retry_count of zero, a single RNR NAK     terminates the connection. Refilling against rb_credits also restores the target that applied to malformed     replies before commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting     Receives) when rpcrdma_post_recvs() computed it from rb_credits internally. rb_credits is at least one     from connection establishment onward, so the repost path always keeps Receives posted. (CVE-2026-72464)

  - In the Linux kernel, the following vulnerability has been resolved: smb: client: avoid using uninitialized     SIDs in cifs_posix_to_fattr() cifs_posix_to_fattr() ignores the return value of posix_info_parse(). When a     malformed POSIX directory entry is encountered (e.g. invalid SID lengths from an untrusted server),     posix_info_parse() returns -1 without populating the 'parsed' struct. The uninitialized stack memory in     parsed.owner and parsed.group is then passed to sid_to_id(), which processes the garbage bytes and passes     them to request_key() to construct a SID string, potentially leaking kernel stack contents to the     userspace idmap daemon. Fix this by checking the return value and skipping the SID-to-id mapping when     parsing fails. The remaining fattr fields (timestamps, mode, etc.) are populated directly from the 'info'     pointer so they are unaffected. (CVE-2026-97554)

  - In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent     states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO:
    rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8     task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec     mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof     alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in     bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on     PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task     never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a     quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1] (CVE-2026-89753)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
367035	Linux Distros 未修补的漏洞：CVE-2026-98853	Nessus	Misc.	2026/10/18	2026/11/14	medium
367035	Linux Distros 未修補弱點：CVE-2026-98853	Nessus	Misc.	2026/10/18	2026/11/14	medium
367035	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98853	Nessus	Misc.	2026/10/18	2026/11/14	medium
367035	Linux Distros Unpatched Vulnerability : CVE-2026-98853	Nessus	Misc.	2026/10/18	2026/11/14	medium
381339	Ubuntu 26.04 LTS : Linux kernel vulnerabilities (USN-9018-1)	Nessus	Ubuntu Local Security Checks	2026/11/14	2026/11/14	critical
381507	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1794654433)	Nessus	Rocky Linux Local Security Checks	2026/11/15	2026/11/15	high
378425	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1794319150)	Nessus	CentOS Local Security Checks	2026/11/10	2026/11/10	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/13	high
381516	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1794654433)	Nessus	Alma Linux Local Security Checks	2026/11/15	2026/11/15	high

偵測

搜尋 Plugin

medium

medium

medium

medium

critical

high

high

high

high