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

  - smb：用戶端：拒絕不符合要求緩衝區的 SetEA 要求 CIFSSMBSetEA（） 會將呼叫端的擴充屬性值複製到 SMB 要求緩衝區，而不檢查它是否適合。該要求在原始碼中說明，但從未實現： /*BB 新增長度檢查以查看它是否適合協商的 SMB 緩衝區大小 BB */ /* if （ea_value_len > buffer_size - 512 （足夠用於標頭）） */ if （ea_value_len） memcpy（parm_data->list.name + name_len + 1， ea_value， ea_value_len）;在進入過程中套用的唯一界限是在 cifs_xattr_set（） 中： #define MAX_EA_VALUE_SIZE CIFSMaxBufSize ...如果 （大小 > MAX_EA_VALUE_SIZE） CIFSMaxBufSize 是緩衝區的完整承載容量，因此該大小的值不會為 SMB 標頭、TRANS2 參數區塊、fealist 標頭和寫入在相同物件前面的 EA 名稱留下空間。SendReceive（） 已對此長度強制執行正確的限制：if （in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE），但在複製發生之後呼叫。具有 250 位元組名稱和 16384 位元組值的 SMB1 掛載上的無權限 setxattr（2） 會將從 345 位元組開始的 16384 位元組寫入 16588 位元組的 cifs_request 物件，並在其後 141 位元組結束： 錯誤： KASAN：CIFSSMBSetEA+0xabc/0xde0 在 addr ffff888003aa0159 處寫入大小為 16384 的寫入 init/68
    __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 有錯誤的位址位於配置的 16588 位元組區域內的 345 位元組 將 SendReceive（） 的限制套用至複製之前而不是之後的組合要求，並擴大位元組計數器，使總和在測試之前無法換行。byte_count也會針對 U16_MAX 進行測試，因為它會儲存在 16 位元 pSMB->ByteCount 中。當 CIFSMaxBufSize 在模組載入時引發時，它可以設定為 1024*127：使用 5 位元組的 EA 名稱和 65521 位元組的值，計數正好U16_MAX，而 byte_count 為 65556，並且 cpu_to_le16（） 會將其截斷為 20 並傳輸 ByteCount 與其長度不匹配的幀。測試byte_count也涵蓋計數，因為 byte_count 是兩者中較大的一個，並且計數唯一的 16 位消費者是在這一點之後寫入的。系統會先評估 check_add_overflow（），以便在報告之前指派total_len。（CVE-2026-99109）

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

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

  - smb：客户端：拒绝不适合请求缓冲区的 SetEA 请求 CIFSSMBSetEA（） 将调用程序的扩展属性值复制到 SMB 请求缓冲区，但未检查该值是否适合。源中说明了要求，但从未实现：/*BB 添加长度检查以查看是否适合协商的 SMB 缓冲区大小 BB */ /* if （ea_value_len > buffer_size - 512（足够用于标头）） */ if （ea_value_len） memcpy（parm_data->list.name + name_len + 1， ea_value， ea_value_len）;在进入过程中应用的唯一边界是在 cifs_xattr_set（） 中： #define MAX_EA_VALUE_SIZE CIFSMaxBufSize ...if （大小 > MAX_EA_VALUE_SIZE） CIFSMaxBufSize 是缓冲区的完整负载容量，因此完全相同大小的值不会给同一对象中写在前面的 SMB 标头、TRANS2 参数块、fealist 标头和 EA 名称留下任何空间。SendReceive（） 已对此长度强制执行正确的限制：if （in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE），但它是在复制发生后调用的。具有 250 字节名称和 16384 字节值的 SMB1 挂载上的非特权 setxattr（2） 会将以 345 字节开头的 16384 字节写入 16588 字节的 cifs_request 对象，在其之后结束 141 字节： 缺陷：KASAN：CIFSSMBSetEA+0xabc/0xde0 在地址处的写入大小为 16384，由任务 init/68 写入
    __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 有缺陷的地址位于分配的 16588 字节区域内 345 字节 在复制之前（而不是复制之后）对组装请求应用 SendReceive（） 的限制，并加宽字节计数器，使总和在测试前无法封装。还针对 U16_MAX 进行测试byte_count，因为它存储在 16 位 pSMB->ByteCount 中。在模块加载时 CIFSMaxBufSize 升高时可达到此值，其可能被设置为高达 1024*127：具有 5 字节 EA 名称和 65521 字节值时，count 正好为 U16_MAX，而 byte_count 为 65556，cpu_to_le16（） 会将其截断为 20，并传输 ByteCount 与其长度不匹配的帧。测试byte_count也涵盖了 count，因为 byte_count 是两者中较大的一个，并且 count 的唯一 16 位使用者在此之后写入。首先评估 check_add_overflow（），以便在报告total_len前分配。（CVE-2026-99109）

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

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

  - smb:client:リクエストバッファに適合しない SetEA リクエストを拒否します CIFSSMBSetEA() は、呼び出し元の拡張属性値が適合することを確認せずに、SMB リクエストバッファにコピーします。要件はソースに記載されていますが、実装されることはありませんでした: /*BB ネゴシエートされた SMB バッファサイズ BB に収まるかどうかを確認するための長さチェックを追加します BB */ /* if (ea_value_len > buffer_size - 512(ヘッダーに十分)) */ if (ea_value_len) memcpy(parm_data->list.name + name_len + 1, ea_value, ea_value_len);途中で適用される唯一のバインドは cifs_xattr_set() です: #define MAX_EA_VALUE_SIZE CIFSMaxBufSize ...(サイズ > MAX_EA_VALUE_SIZE) CIFSMaxBufSize がバッファのフルペイロード容量である場合、ちょうどそのサイズの値は、同じオブジェクト内でその前に書き込まれる SMB ヘッダー、TRANS2 パラメーターブロック、fealist ヘッダー、および EA 名のための余地を残しません。SendReceive() はすでにこの長さに正しい制限を強制しています: if (in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE) ですが、コピーが行われた後に呼び出されます。250 バイトの名前と 16384 バイトの値を持つ SMB1 マウントの権限のない setxattr(2) が、16388 バイトの cifs_request オブジェクトに 345 バイトから始まる 16384 バイトを書き込み、141 バイトを超えて終了します: バグ: KASAN:0xde0 0xabcタスク init/68 による addr ffff888003aa0159 でのサイズ 16384 の書き込み
    __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 バグのあるアドレスが、割り当てられた 16588 バイトの領域の 345 バイトに位置しています SendReceive() の制限を、コピーの後ではなくコピーの前に適用し、テスト前に合計がラップされないようにバイトカウンターを広げます。byte_countは16ビットのpSMB->ByteCountに格納されるため、U16_MAXに対してもテストされます。これは、モジュールのロードで CIFSMaxBufSize が発生したときに到達可能になり、1024*127 まで高く設定される可能性があります:5 バイトの EA 名と 65521 バイトの値がある場合、カウントは正確にU16_MAXですが、byte_count は 65556 であり、cpu_to_le16() はこれを 20 に切り捨て、ByteCount がその長さに一致しないフレームを送信します。byte_countは 2 つのうち大きい方であり、カウントの唯一の 16 ビットコンシューマーはこの時点より後に書き込まれるため、テストbyte_countカウントもカバーします。check_add_overflow() は、報告される前にtotal_lenが割り当てられるように最初に評価されます。(CVE-2026-99109)

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

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

  - 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: iommufd: Prevent ALIGN() overflow When     allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to     ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using     get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length     earlier either. Consolidate the two copies of this code under a single helper. This bug would allow     userspace to create a mapping that overlaps with some other mapping or a reserved range. (CVE-2025-38688)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in     ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is     not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-39991)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-     bounds writes in handle_auth_session_key() The len field originates from untrusted network packets.
    Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection     secret or processing service tickets. [ idryomov: changelog ] (CVE-2025-68284)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on     duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on     every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
    Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to     65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the     affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs     before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents     the underflow path. (CVE-2026-31662)

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:1793866396 advisory.

  - 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: iommufd: Prevent ALIGN() overflow When     allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to     ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using     get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length     earlier either. Consolidate the two copies of this code under a single helper. This bug would allow     userspace to create a mapping that overlaps with some other mapping or a reserved range. (CVE-2025-38688)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in     ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is     not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len.
    Found by Linux Verification Center (linuxtesting.org) with SVACE. (CVE-2025-39991)

  - In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-     bounds writes in handle_auth_session_key() The len field originates from untrusted network packets.
    Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection     secret or processing service tickets. [ idryomov: changelog ] (CVE-2025-68284)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on     duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on     every inbound group ACK, even when the same member has already acknowledged the current broadcast round.
    Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to     65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the     affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs     before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents     the underflow path. (CVE-2026-31662)

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

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

  - smb: client: reject SetEA requests that do not fit the request buffer CIFSSMBSetEA() copies the caller's     extended attribute value into the SMB request buffer without checking that it fits. The requirement is     stated in the source but was never implemented: /*BB add length check to see if it would fit in negotiated     SMB buffer size BB */ /* if (ea_value_len > buffer_size - 512 (enough for header)) */ if (ea_value_len)     memcpy(parm_data->list.name + name_len + 1, ea_value, ea_value_len); The only bound applied on the way in     is in cifs_xattr_set(): #define MAX_EA_VALUE_SIZE CIFSMaxBufSize ... if (size > MAX_EA_VALUE_SIZE)     CIFSMaxBufSize is the full payload capacity of the buffer, so a value of exactly that size leaves no room     for the SMB header, the TRANS2 parameter block, the fealist header and the EA name that are written ahead     of it in the same object. SendReceive() already enforces the correct limit on this very length: if (in_len     > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE) but it is called after the copy has taken place. An unprivileged     setxattr(2) on an SMB1 mount with a 250-byte name and a 16384-byte value writes 16384 bytes starting 345     bytes into a 16588-byte cifs_request object, ending 141 bytes past it: BUG: KASAN: slab-out-of-bounds in     CIFSSMBSetEA+0xabc/0xde0 Write of size 16384 at addr ffff888003aa0159 by task init/68
    __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 The     buggy address is located 345 bytes inside of allocated 16588-byte region Apply SendReceive()'s limit to     the assembled request before the copy rather than after it, and widen the byte counters so the sum cannot     wrap before it is tested. byte_count is also tested against U16_MAX, because it is stored in the 16-bit     pSMB->ByteCount. That becomes reachable when CIFSMaxBufSize is raised at module load, where it may be set     as high as 1024*127: with a 5-byte EA name and a 65521-byte value, count is exactly U16_MAX while     byte_count is 65556, and cpu_to_le16() would truncate it to 20 and transmit a frame whose ByteCount does     not match its length. Testing byte_count covers count as well, since byte_count is the larger of the two     and count's only 16-bit consumer is written after this point. check_add_overflow() is evaluated first so     that total_len is assigned before it is reported. (CVE-2026-99109)

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.

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	名稱	產品	系列	已發布	已更新	嚴重性
373330	Linux Distros 未修補弱點：CVE-2026-99109	Nessus	Misc.	2026/10/28	2026/11/14	high
373330	Linux Distros 未修补的漏洞：CVE-2026-99109	Nessus	Misc.	2026/10/28	2026/11/14	high
373330	Linux Distros のパッチ未適用の脆弱性: CVE-2026-99109	Nessus	Misc.	2026/10/28	2026/11/14	high
376433	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793866396)	Nessus	Alma Linux Local Security Checks	2026/11/5	2026/11/5	high
376432	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793866396)	Nessus	Rocky Linux Local Security Checks	2026/11/5	2026/11/5	high
373330	Linux Distros Unpatched Vulnerability : CVE-2026-99109	Nessus	Misc.	2026/10/28	2026/11/14	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

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high