The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the CIQ ciqsa-2026_1794 advisory.

    This advisory aggregates security fixes for the kernel SRPM in CIQ FIPS 9.6 Compliant. It addresses 28     CVEs: CVE-2026-64320, CVE-2026-72243, CVE-2026-64562, CVE-2026-64490, CVE-2025-71066, and 23 more.

Tenable has extracted the preceding description block directly from the CIQ 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: Fix potential UAF in reqsk_timer_handler(). When TCP socket migration fails at inet_ehash_insert() in     reqsk_timer_handler(), we jump to the no_ownership: label and free the new reqsk immediately with
    __reqsk_free(). Thus, we must stop the new reqsk's timer before jumping to the label, but the timer might     be missed since the cited commit, resulting in UAF. As we are in the original reqsk's timer context, we     can safely call timer_delete_sync() for the new reqsk. Let's pass false to __inet_csk_reqsk_queue_drop()     to stop the new reqsk's timer. (CVE-2026-99270)

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

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 remote Oracle Linux 8 / 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-500631 advisory.

    - inet: reject unhashed sockets during established lookups (Hyunwoo Kim)  [Orabug: 40285605]     {CVE-2026-99288}

Tenable has extracted the preceding description block directly from the Oracle Linux 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 remote Oracle Linux 10 / 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-500632 advisory.

    - inet: reject unhashed sockets during established lookups (Hyunwoo Kim)  [Orabug: 40285160]     {CVE-2026-99288}

Tenable has extracted the preceding description block directly from the Oracle Linux 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 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	名稱	產品	系列	已發布	已更新	嚴重性
381036	Rocky Linux 9.6 [CIQ] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ciqsa-2026_1794)	Nessus	Rocky Linux Local Security Checks	2026/11/14	2026/11/14	high
375807	Linux Distros Unpatched Vulnerability : CVE-2026-99270	Nessus	Misc.	2026/11/4	2026/11/14	high
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
380351	Oracle Linux 8 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500631)	Nessus	Oracle Linux Local Security Checks	2026/11/13	2026/11/13	high
380634	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500632)	Nessus	Oracle Linux Local Security Checks	2026/11/13	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

high

high

high

high

high

high