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

  - ipv6：防止fib6_info终止的 rt6_insert_exception（）。在引用的提交之前，fib6_nh_flush_exceptions（） 始终在 rt6_exception_lock 下设置 from->exception_bucket_flushed = 1，以防止 rt6_insert_exception（） 为垂死的fib6_info插入新的异常。此标志已替换为 nh->rt6i_exception_bucket 中存储的 FIB6_EXCEPTION_BUCKET_FLUSHED 位。问题是现在只有在存储段不是 NULL 时才设置该位，并且在 fib6_ref 已经达到零之后从 fib6_nh_release（） 调用 fib6_nh_flush_exceptions（）。如果在通过 fib6_purge_rt（） 删除目标fib6_info时调用 rt6_insert_exception（），由于 rt6_flush_exceptions（） 不再设置该位，因此可成功创建新的异常。这会在 fib6_info 和异常路由之间创建引用循环，泄露 fib6_info、其 nexthop 设备以及 fib6_nh->rt6i_pcpu 中所有每个 CPU 的路由，从而停止 netdev 取消注册。[ 34.680602] unregister_netdevice：等待 gre6 释放。使用计数 = 68 [ 44.920675] unregister_netdevice：等待 gre6 释放。
    使用计数 = 68 [ 55.176582] unregister_netdevice：等待 gre6 释放。使用次数 = 68 我们在 rt6_flush_exceptions（） 之前调用 fib6_drop_pcpu_from（），在 rt6_exception_lock 之前设置 fib6_destroying，并在 rt6_insert_exception（） 中检查 f6i->fib6_destroying。请注意，FIB6_EXCEPTION_BUCKET_FLUSHED逻辑已失效，可在 net-next 中清理。（CVE-2026-98598）

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

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

  - ipv6：防止 rt6_insert_exception（） fib6_info瀕死。在引用的提交之前，fib6_nh_flush_exceptions（） 始終在 rt6_exception_lock 下設置 from->exception_bucket_flushed = 1，以防止 rt6_insert_exception（） 為垂死的fib6_info插入新的例外。旗標已取代為儲存在 nh->rt6i_exception_bucket 中的 FIB6_EXCEPTION_BUCKET_FLUSHED 位元。問題是，現在只有當儲存桶不是 NULL 並且在 fib6_ref 已經達到零後從 fib6_nh_release（） 呼叫 fib6_nh_flush_exceptions（） 時才設定位元。如果在透過 fib6_purge_rt（） 移除目標fib6_info時呼叫 rt6_insert_exception（），則可以成功建立新的例外狀況，因為 rt6_flush_exceptions（） 不再設定位元。這會在fib6_info和異常路由之間建立參照週期，洩漏 fib6_info、其 nexthop 裝置，以及 fib6_nh->rt6i_pcpu 中的所有 per-CPU 路由，進而停止 netdev 取消註冊。[ 34.680602] unregister_netdevice：等待 gre6 釋放。使用計數 = 68 [ 44.920675] unregister_netdevice：等待 gre6 釋放。
    使用計數 = 68 [ 55.176582] unregister_netdevice：等待 gre6 釋放。使用次數 = 68 讓我們在 rt6_flush_exceptions（） 之前呼叫 fib6_drop_pcpu_from（），在 rt6_exception_lock 之前設定 fib6_destroying，並在 rt6_insert_exception（） 中檢查 f6i->fib6_destroying。請注意，FIB6_EXCEPTION_BUCKET_FLUSHED邏輯已失效，我們可以在 net-next 中清理它。（CVE-2026-98598）

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

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

  - ipv6:rt6_insert_exception() が機能しなくなったfib6_infoを防止します。引用されたコミットの前に、fib6_nh_flush_exceptions() は常に from->exception_bucket_flushed = 1 を rt6_exception_lock の下に設定して、rt6_insert_exception() が瀕死のfib6_infoの新しい例外を挿入することを防ぎます。フラグは、nh->rt6i_exception_bucketに保存されている FIB6_EXCEPTION_BUCKET_FLUSHED ビットで置き換えられました。問題は、バケットが NULL ではなく、fib6_ref がすでにゼロに達した後に fib6_nh_flush_exceptions() が fib6_nh_release() から呼び出される場合のみ、ビットが設定されるようになることです。ターゲットfib6_infoが fib6_purge_rt() により削除されているときに rt6_insert_exception() が呼び出された場合、rt6_flush_exceptions() がビットを設定しなくなるため、新しい例外が正常に作成される可能性があります。これは、fib6_info と例外ルートの間に参照サイクルを作成し、fib6_info、その nexthop デバイス、および fib6_nh->rt6i_pcpu 内のすべての CPU ごとのルートを漏洩し、netdev の登録解除を停止させます。[ 34.680602] unregister_netdevice:gre6 が解放されるのを待機します。使用カウント = 68 [ 44.920675] unregister_netdevice:gre6 が解放されるのを待機。
    使用カウント = 68 [ 55.176582] unregister_netdevice:gre6 が解放されるのを待機。使用回数 = 68 rt6_flush_exceptions() の前に fib6_drop_pcpu_from() を呼び出して、rt6_exception_lock の前に fib6_destroying を設定し、rt6_insert_exception() の f6i->fib6_destroying をチェックしましょう。注意:FIB6_EXCEPTION_BUCKET_FLUSHEDロジックは機能していないため、net-next でクリーンアップできます。(CVE-2026-98598)

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

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

  - ipv6: Prevent rt6_insert_exception() for dying fib6_info. Before the cited commit,     fib6_nh_flush_exceptions() always set from->exception_bucket_flushed = 1 under rt6_exception_lock to     prevent rt6_insert_exception() from inserting a new exception for a dying fib6_info. The flag was replaced     with the FIB6_EXCEPTION_BUCKET_FLUSHED bit stored in nh->rt6i_exception_bucket. The problem is that now     the bit is only set when the bucket is not NULL and fib6_nh_flush_exceptions() is called from     fib6_nh_release() after fib6_ref has already reached zero. If rt6_insert_exception() is called while the     target fib6_info is being removed via fib6_purge_rt(), a new exception could be created successfully     because rt6_flush_exceptions() no longer sets the bit. This creates a reference cycle between the     fib6_info and the exception route, leaking the fib6_info, its nexthop device, and all per-CPU routes in     fib6_nh->rt6i_pcpu, which stalls netdev unregistration. [ 34.680602] unregister_netdevice: waiting for     gre6 to become free. Usage count = 68 [ 44.920675] unregister_netdevice: waiting for gre6 to become free.
    Usage count = 68 [ 55.176582] unregister_netdevice: waiting for gre6 to become free. Usage count = 68     Let's call fib6_drop_pcpu_from() before rt6_flush_exceptions(), to set fib6_destroying before     rt6_exception_lock, and check f6i->fib6_destroying in rt6_insert_exception(). Note that     FIB6_EXCEPTION_BUCKET_FLUSHED logic is dead and we can clean it up in net-next. (CVE-2026-98598)

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	名稱	產品	系列	已發布	已更新	嚴重性
367072	Linux Distros 未修补的漏洞：CVE-2026-98598	Nessus	Misc.	2026/10/18	2026/11/13	medium
371850	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3251)	Nessus	Amazon Linux Local Security Checks	2026/10/25	2026/11/2	critical
371850	Amazon Linux 2023：bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3251)	Nessus	Amazon Linux Local Security Checks	2026/10/25	2026/11/2	critical
367072	Linux Distros 未修補弱點：CVE-2026-98598	Nessus	Misc.	2026/10/18	2026/11/13	medium
367072	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98598	Nessus	Misc.	2026/10/18	2026/11/13	medium
371850	Amazon Linux 2023 : bpftool6.18、kernel6.18、kernel6.18-devel (ALAS2023-2026-3251)	Nessus	Amazon Linux Local Security Checks	2026/10/25	2026/11/2	critical
367072	Linux Distros Unpatched Vulnerability : CVE-2026-98598	Nessus	Misc.	2026/10/18	2026/11/13	medium
371850	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3251)	Nessus	Amazon Linux Local Security Checks	2026/10/25	2026/11/2	critical
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
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	2026/11/5	2026/11/5	high

偵測

搜尋 Plugin

medium

critical

critical

medium

medium

critical

medium

critical

high

high