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

  - wifi：cfg80211：将 wiphy 从垂死的网络命名空间中取出 当网络命名空间遭到破坏时，cfg80211_pernet_exit（） 会将任何 wiphy 移回初始命名空间，并且只是在失败时发出警告。但是移动接口可能会失败（由于分配失败），然后 wiphy 会被留下一个垃圾 netns 指针：地址 0x30 genlmsg_multicast_netns.constprop.0+0x46/0xcf 的内核模式错误 [cfg80211] nl80211_notify_wiphy+0xcd/0xe8 [cfg80211] wiphy_unregister+0x169/0x3fc [cfg80211] 请注意，提交 debac3a20dec（net：删除 __dev_change_net_namespace（）） 中垂死的 netns 的冲突 altnames。） 修复了可在不发生分配失败的情况下到达该地址的其他路径。删除无法移动的接口，而不是使切换发生故障，以便 wiphy 始终在初始命名空间结束。在这种情况下，netdev 核心将始终取消接口的注册。（CVE-2026-98330）

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

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

  - wifi： cfg80211：將 wiphy 從垂死的網路命名空間中取出 當網路命名空間被破壞時，cfg80211_pernet_exit（） 會將任何 wiphy 移回初始命名空間，並在失敗時發出警告。但是移動介面可能會失敗（由於分配失敗），然後 wiphy 會留下一個垃圾 netns 指標： addr 0x30 genlmsg_multicast_netns.constprop.0+0x46/0xcf 的核心模式錯誤 [cfg80211] nl80211_notify_wiphy+0xcd/0xe8 [cfg80211] wiphy_unregister+0x169/0x3fc [cfg80211] 請注意，提交 debac3a20dec （net：刪除 __dev_change_net_namespace（）） 中垂死 netns 的衝突 altnames 已修正另一條可以在不分配失敗的情況下到達它的路徑。移除無法移動的介面，而不是使交換器失敗，以便 wiphy 一律位於初始命名空間中。在這種情況下，netdev 核心無論如何都會取消註冊介面。（CVE-2026-98330）

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

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

  - wifi:cfg80211:機能しなくなっているネットワーク名前空間から wiphy を取り出します。ネットワーク名前空間が破壊されると、cfg80211_pernet_exit() は任意の wiphy を初期の名前空間に戻します。そして、それが失敗した場合は警告のみを出します。ただし、インターフェイスの移動は(割り当ての失敗により)失敗し、wiphy はガベージ netns ポインターで取り残される可能性があります:addr 0x30 genlmsg_multicast_netns.constprop.0+0x46/0xcf でのカーネルモード障害 [cfg80211] nl80211_notify_wiphy+0xcd/0xe8 [cfg80211] wiphy_unregister+0x169/0x3fc [cfg80211] 注意:commit debac3a20dec(net:__dev_change_net_namespace().) の死んでいる netns に対する競合する altnames を削除します。)は、割り当てエラーなしに到達できる別のパスを修正しました。スイッチを失敗させる代わりに、移動できないインターフェイスを削除します。これにより、wiphy が常に初期の名前空間で終了するようにします。この場合、netdev core はインターフェイスの登録を解除します。(CVE-2026-98330)

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

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

  - wifi: cfg80211: get the wiphy out of a dying network namespace When a network namespace is destroyed,     cfg80211_pernet_exit() moves any wiphy back to the initial namespace, and just warns if that fails. But     moving an interface can fail (due to allocation failures), and then the wiphy is left behind with a     garbage netns pointer: Kernel mode fault at addr 0x30 genlmsg_multicast_netns.constprop.0+0x46/0xcf     [cfg80211] nl80211_notify_wiphy+0xcd/0xe8 [cfg80211] wiphy_unregister+0x169/0x3fc [cfg80211] Note that     commit debac3a20dec (net: Remove conflicting altnames for dying netns in __dev_change_net_namespace().)     fixed another path that could reach it without allocation failures. Remove interfaces that cannot be moved     instead of failing the switch, so that the wiphy always ends up in the initial namespace. In this case the     netdev core will unregister the interfaces anyway. (CVE-2026-98330)

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

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.

ID	名前	製品	ファミリー	公開日	更新日	深刻度
363190	Linux Distros 未修补的漏洞：CVE-2026-98330	Nessus	Misc.	2026/10/6	2026/11/11	high
363190	Linux Distros 未修補弱點：CVE-2026-98330	Nessus	Misc.	2026/10/6	2026/11/11	high
363190	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98330	Nessus	Misc.	2026/10/6	2026/11/11	high
363190	Linux Distros Unpatched Vulnerability : CVE-2026-98330	Nessus	Misc.	2026/10/6	2026/11/11	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
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

検出

プラグインの検索

high

high

high

high

high

high