The remote Debian 13 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-6568 advisory.

    - -------------------------------------------------------------------------     Debian Security Advisory DSA-6568-1                   security@debian.org     https://www.debian.org/security/                     Salvatore Bonaccorso     October 16, 2026                      https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    Package        : linux     CVE ID         : CVE-2025-38204 CVE-2025-40158 CVE-2026-52988 CVE-2026-72315                      CVE-2026-72463 CVE-2026-74347 CVE-2026-80935 CVE-2026-80937                      CVE-2026-80939 CVE-2026-80980 CVE-2026-81016 CVE-2026-89437                      CVE-2026-89441 CVE-2026-89445 CVE-2026-89452 CVE-2026-89467                      CVE-2026-89500 CVE-2026-89503 CVE-2026-89520 CVE-2026-89527                      CVE-2026-89633 CVE-2026-89638 CVE-2026-89766 CVE-2026-89795                      CVE-2026-89797 CVE-2026-89806 CVE-2026-89827 CVE-2026-89832                      CVE-2026-89837 CVE-2026-89838 CVE-2026-89840 CVE-2026-89859                      CVE-2026-89868 CVE-2026-89912 CVE-2026-89921 CVE-2026-89956                      CVE-2026-89971 CVE-2026-89972 CVE-2026-89996 CVE-2026-90002                      CVE-2026-90013 CVE-2026-90016 CVE-2026-90023 CVE-2026-90029                      CVE-2026-90030 CVE-2026-90146 CVE-2026-93179 CVE-2026-93196                      CVE-2026-93199 CVE-2026-93200 CVE-2026-93231 CVE-2026-93243                      CVE-2026-93244 CVE-2026-93285 CVE-2026-97527 CVE-2026-97528                      CVE-2026-97529 CVE-2026-97530 CVE-2026-97531 CVE-2026-97532                      CVE-2026-97534 CVE-2026-97535 CVE-2026-97536 CVE-2026-97537                      CVE-2026-97549 CVE-2026-97558 CVE-2026-97559 CVE-2026-97566                      CVE-2026-97567 CVE-2026-97571 CVE-2026-97574 CVE-2026-97594                      CVE-2026-97597 CVE-2026-97603 CVE-2026-97609 CVE-2026-97615                      CVE-2026-97618 CVE-2026-97619 CVE-2026-97620 CVE-2026-97901                      CVE-2026-97906 CVE-2026-97918 CVE-2026-97919 CVE-2026-97933                      CVE-2026-97934 CVE-2026-97935 CVE-2026-97938 CVE-2026-97939                      CVE-2026-97949 CVE-2026-97950 CVE-2026-98101 CVE-2026-98161                      CVE-2026-98167 CVE-2026-98168 CVE-2026-98169 CVE-2026-98170                      CVE-2026-98171 CVE-2026-98172 CVE-2026-98173 CVE-2026-98174                      CVE-2026-98175 CVE-2026-98179 CVE-2026-98181 CVE-2026-98182                      CVE-2026-98184 CVE-2026-98185 CVE-2026-98186 CVE-2026-98187                      CVE-2026-98188 CVE-2026-98189 CVE-2026-98190 CVE-2026-98191                      CVE-2026-98192 CVE-2026-98193 CVE-2026-98194 CVE-2026-98195                      CVE-2026-98196 CVE-2026-98197 CVE-2026-98198 CVE-2026-98199                      CVE-2026-98200 CVE-2026-98201 CVE-2026-98202 CVE-2026-98203                      CVE-2026-98204 CVE-2026-98205 CVE-2026-98206 CVE-2026-98207                      CVE-2026-98208 CVE-2026-98209 CVE-2026-98210 CVE-2026-98211                      CVE-2026-98212 CVE-2026-98213 CVE-2026-98214 CVE-2026-98215                      CVE-2026-98216 CVE-2026-98217 CVE-2026-98218 CVE-2026-98221                      CVE-2026-98222 CVE-2026-98227 CVE-2026-98229 CVE-2026-98230                      CVE-2026-98231 CVE-2026-98232 CVE-2026-98233 CVE-2026-98234                      CVE-2026-98235 CVE-2026-98236 CVE-2026-98237 CVE-2026-98238                      CVE-2026-98239 CVE-2026-98241 CVE-2026-98245 CVE-2026-98246                      CVE-2026-98247 CVE-2026-98248 CVE-2026-98249 CVE-2026-98251                      CVE-2026-98252 CVE-2026-98253 CVE-2026-98254 CVE-2026-98255                      CVE-2026-98257 CVE-2026-98260 CVE-2026-98261 CVE-2026-98262                      CVE-2026-98263 CVE-2026-98264 CVE-2026-98265 CVE-2026-98266                      CVE-2026-98267 CVE-2026-98269 CVE-2026-98270 CVE-2026-98271                      CVE-2026-98272 CVE-2026-98275 CVE-2026-98276 CVE-2026-98282                      CVE-2026-98283 CVE-2026-98287 CVE-2026-98290 CVE-2026-98291                      CVE-2026-98293 CVE-2026-98295 CVE-2026-98297 CVE-2026-98298                      CVE-2026-98299 CVE-2026-98300 CVE-2026-98301 CVE-2026-98302                      CVE-2026-98303 CVE-2026-98306 CVE-2026-98307 CVE-2026-98308                      CVE-2026-98309 CVE-2026-98311 CVE-2026-98312 CVE-2026-98314                      CVE-2026-98316 CVE-2026-98319 CVE-2026-98320 CVE-2026-98322                      CVE-2026-98323 CVE-2026-98325 CVE-2026-98326 CVE-2026-98327                      CVE-2026-98328 CVE-2026-98329 CVE-2026-98331 CVE-2026-98334                      CVE-2026-98335 CVE-2026-98336 CVE-2026-98337 CVE-2026-98339                      CVE-2026-98340 CVE-2026-98342 CVE-2026-98343 CVE-2026-98344                      CVE-2026-98345 CVE-2026-98346 CVE-2026-98347 CVE-2026-98348                      CVE-2026-98349 CVE-2026-98351 CVE-2026-98352 CVE-2026-98354                      CVE-2026-98357 CVE-2026-98358 CVE-2026-98359 CVE-2026-98360                      CVE-2026-98362 CVE-2026-98363 CVE-2026-98365 CVE-2026-98366                      CVE-2026-98367 CVE-2026-98368 CVE-2026-98369 CVE-2026-98370                      CVE-2026-98373 CVE-2026-98374 CVE-2026-98375 CVE-2026-98377                      CVE-2026-98378 CVE-2026-98379 CVE-2026-98380 CVE-2026-98381                      CVE-2026-98382 CVE-2026-98383 CVE-2026-98384 CVE-2026-98386                      CVE-2026-98403 CVE-2026-98406 CVE-2026-98407 CVE-2026-98409                      CVE-2026-98410 CVE-2026-98411 CVE-2026-98412 CVE-2026-98413                      CVE-2026-98416 CVE-2026-98417 CVE-2026-98419 CVE-2026-98421                      CVE-2026-98422 CVE-2026-98423 CVE-2026-98425 CVE-2026-98426                      CVE-2026-98428 CVE-2026-98429 CVE-2026-98430 CVE-2026-98432                      CVE-2026-99999     Debian Bug     : 1149499 1149564 1150891

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For the stable distribution (trixie), these problems have been fixed in     version 6.12.113-1.

    We recommend that you upgrade your linux packages.

    For the detailed security status of linux please refer to its security     tracker page at:
    https://security-tracker.debian.org/tracker/linux

    Further information about Debian Security Advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

Tenable has extracted the preceding description block directly from the Debian 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 Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - tcp: do not let tcp_rmem be set below 4096 We can hit a division by zero crash in tcp_rcvbuf_grow() and     tcp_rcv_space_adjust(): divide error: 0000 [#1] PREEMPT SMP RIP: 0010:tcp_rcvbuf_grow+0x187/0x450     net/ipv4/tcp_input.c:939 ... grow = div_u64(((u64)rcvwin << 1) * (newval - oldval), oldval); The division     uses oldval = tp->rcvq_space.space as divisor. When tp->rcvq_space.space is zero, this leads to a divide-     by-zero exception. tp->rcvq_space.space is initialized in tcp_init_buffer_space(): tp->rcvq_space.space =     min3(tp->rcv_ssthresh, tp->rcv_wnd, (u32)TCP_INIT_CWND * tp->advmss); If tcp_rmem[1] is configured to very     small values (such as 1), sk->sk_rcvbuf is initialized to 1. Then tcp_full_space(sk), which computes     (sk->sk_rcvbuf * scaling_ratio) >> 8, truncates to 0. This sets tp->window_clamp = 0, tp->rcv_ssthresh =     0, and tp->rcvq_space.space = 0. Later, when data arrives and DRS is invoked, tcp_rcvbuf_grow() divides by     oldval == 0. Back in 2015, commit b1cb59cf2efe (net: sysctl_net_core: check SNDBUF and RCVBUF for min     length) ensured that net.core.rmem_default and net.core.rmem_max cannot be set below SOCK_MIN_RCVBUF.
    Similarly, SO_RCVBUF setsockopt enforces max_t(int, val * 2, SOCK_MIN_RCVBUF). However, net.ipv4.tcp_rmem     still had .extra1 = SYSCTL_ONE, allowing arbitrarily small values. Because SOCK_MIN_RCVBUF depends on     sizeof(struct sk_buff) and cacheline alignment, its value varies across architectures and configuration     options. Using a fixed constant of 4096 ensures a predictable, architecture- independent lower bound that     is safely above SOCK_MIN_RCVBUF everywhere and matches the documented 4K default. Fix this by setting     tcp_rmem.extra1 to 4096 and updating the documentation. (CVE-2026-98299)

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

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	名稱	產品	系列	已發布	已更新	嚴重性
365258	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/29	high
366507	Debian dsa-6568 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	2026/10/16	2026/10/19	high
363246	Linux Distros Unpatched Vulnerability : CVE-2026-98299	Nessus	Misc.	2026/10/6	2026/11/14	medium
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

high

high

medium

high