Detections
Analytics

Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1794654433)

high Nessus Plugin ID 381507

Synopsis

The Rocky Linux host is missing one or more security updates.

Description

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.

Solution

Update the affected packages based on the guidance in TuxCare advisory ALMALINUX9.6:CLSA-2026:1794654433.

See Also

https://cve.tuxcare.com/els/releases/CLSA-2026:1794654433

http://www.nessus.org/u?0e327d45

Plugin Details

Severity: High

ID: 381507

File Name: tuxcare_rocky_linux_9.6_CLSA-2026-1794654433.nasl

Version: 1.1

Type: Local

Published: 11/15/2026

Updated: 11/15/2026

Supported Sensors: Continuous Assessment, Nessus Agent, Nessus

Risk Information

VPR

Risk Factor: High

Score: 7.7

Percentile: 99.03

Vendor

Vendor Severity: Important

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5.3

Vector: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C

CVSS Score Source: CVE-2026-100072

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 7

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Temporal Vector: CVSS:3.0/E:P/RL:O/RC:C

CVSS v4

Risk Factor: High

Base Score: 7.3

Threat Score: 6.4

Threat Vector: CVSS:4.0/E:P

Vector: CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

CVSS Score Source: CVE-2025-54518

Vulnerability Information

Required KB Items: Host/OS/extended-third-party, Host/local_checks_enabled, Host/RockyLinux/release, Host/RockyLinux/rpm-list, Host/cpu

Exploit Available: true

Exploit Ease: Exploits are available

Patch Publication Date: 11/14/2026

Vulnerability Publication Date: 7/21/2021

Reference Information

CVE: CVE-2023-53250, CVE-2023-54128, CVE-2023-54236, CVE-2024-50076, CVE-2024-56714, CVE-2025-23133, CVE-2025-37843, CVE-2025-37981, CVE-2025-38134, CVE-2025-38149, CVE-2025-38255, CVE-2025-38265, CVE-2025-38307, CVE-2025-38315, CVE-2025-38369, CVE-2025-38402, CVE-2025-38450, CVE-2025-38646, CVE-2025-39992, CVE-2025-40000, CVE-2025-40051, CVE-2025-40261, CVE-2025-54518, CVE-2025-68171, CVE-2025-68227, CVE-2025-68244, CVE-2025-68297, CVE-2025-68378, CVE-2025-68758, CVE-2026-100072, CVE-2026-23057, CVE-2026-31674, CVE-2026-31774, CVE-2026-43022, CVE-2026-43116, CVE-2026-43161, CVE-2026-43420, CVE-2026-43484, CVE-2026-45894, CVE-2026-45912, CVE-2026-45919, CVE-2026-46054, CVE-2026-46149, CVE-2026-46174, CVE-2026-46291, CVE-2026-52924, CVE-2026-52967, CVE-2026-53049, CVE-2026-53069, CVE-2026-53258, CVE-2026-53352, CVE-2026-53402, CVE-2026-63809, CVE-2026-63858, CVE-2026-63897, CVE-2026-63902, CVE-2026-63904, CVE-2026-63961, CVE-2026-63974, CVE-2026-63990, CVE-2026-64126, CVE-2026-64205, CVE-2026-64296, CVE-2026-64316, CVE-2026-64374, CVE-2026-64411, CVE-2026-64435, CVE-2026-64458, CVE-2026-64474, CVE-2026-64479, CVE-2026-64481, CVE-2026-64511, CVE-2026-64515, CVE-2026-64517, CVE-2026-64527, CVE-2026-64540, CVE-2026-64549, CVE-2026-64551, CVE-2026-64553, CVE-2026-64554, CVE-2026-64556, CVE-2026-68082, CVE-2026-68149, CVE-2026-68192, CVE-2026-68284, CVE-2026-68293, CVE-2026-68406, CVE-2026-68407, CVE-2026-68469, CVE-2026-72004, CVE-2026-72020, CVE-2026-72021, CVE-2026-72049, CVE-2026-72065, CVE-2026-72067, CVE-2026-72073, CVE-2026-72101, CVE-2026-72127, CVE-2026-72129, CVE-2026-72172, CVE-2026-72213, CVE-2026-72221, CVE-2026-72222, CVE-2026-72238, CVE-2026-72245, CVE-2026-72247, CVE-2026-72251, CVE-2026-72253, CVE-2026-72266, CVE-2026-72298, CVE-2026-72319, CVE-2026-72320, CVE-2026-72326, CVE-2026-72330, CVE-2026-72338, CVE-2026-72349, CVE-2026-72379, CVE-2026-72392, CVE-2026-72396, CVE-2026-72405, CVE-2026-72421, CVE-2026-72428, CVE-2026-72441, CVE-2026-72444, CVE-2026-72464, CVE-2026-72473, CVE-2026-74269, CVE-2026-74279, CVE-2026-74284, CVE-2026-74301, CVE-2026-74339, CVE-2026-74382, CVE-2026-74440, CVE-2026-74476, CVE-2026-74492, CVE-2026-74495, CVE-2026-74509, CVE-2026-74510, CVE-2026-74527, CVE-2026-74531, CVE-2026-74533, CVE-2026-74557, CVE-2026-74577, CVE-2026-74579, CVE-2026-74586, CVE-2026-74594, CVE-2026-74595, CVE-2026-74598, CVE-2026-74611, CVE-2026-74612, CVE-2026-74613, CVE-2026-74615, CVE-2026-74620, CVE-2026-74635, CVE-2026-74654, CVE-2026-74662, CVE-2026-74668, CVE-2026-74676, CVE-2026-74678, CVE-2026-74683, CVE-2026-74726, CVE-2026-74748, CVE-2026-74753, CVE-2026-80528, CVE-2026-80539, CVE-2026-80557, CVE-2026-80578, CVE-2026-80585, CVE-2026-80689, CVE-2026-80692, CVE-2026-80693, CVE-2026-80707, CVE-2026-80755, CVE-2026-80767, CVE-2026-80824, CVE-2026-80829, CVE-2026-80837, CVE-2026-80844, CVE-2026-80932, CVE-2026-80941, CVE-2026-80989, CVE-2026-80996, CVE-2026-89487, CVE-2026-89511, CVE-2026-89536, CVE-2026-89539, CVE-2026-89548, CVE-2026-89560, CVE-2026-89561, CVE-2026-89565, CVE-2026-89574, CVE-2026-89583, CVE-2026-89626, CVE-2026-89628, CVE-2026-89631, CVE-2026-89634, CVE-2026-89650, CVE-2026-89652, CVE-2026-89655, CVE-2026-89662, CVE-2026-89686, CVE-2026-89693, CVE-2026-89696, CVE-2026-89700, CVE-2026-89705, CVE-2026-89710, CVE-2026-89713, CVE-2026-89717, CVE-2026-89752, CVE-2026-89753, CVE-2026-89756, CVE-2026-89784, CVE-2026-89803, CVE-2026-89816, CVE-2026-89846, CVE-2026-89852, CVE-2026-89864, CVE-2026-89865, CVE-2026-89879, CVE-2026-89944, CVE-2026-89982, CVE-2026-89999, CVE-2026-90013, CVE-2026-90025, CVE-2026-90031, CVE-2026-90034, CVE-2026-90036, CVE-2026-90053, CVE-2026-90054, CVE-2026-90058, CVE-2026-90075, CVE-2026-90076, CVE-2026-90087, CVE-2026-90099, CVE-2026-90102, CVE-2026-90104, CVE-2026-90109, CVE-2026-90110, CVE-2026-90114, CVE-2026-90125, CVE-2026-90185, CVE-2026-90187, CVE-2026-90206, CVE-2026-90216, CVE-2026-90230, CVE-2026-90248, CVE-2026-90256, CVE-2026-90283, CVE-2026-90293, CVE-2026-90294, CVE-2026-90307, CVE-2026-90317, CVE-2026-90318, CVE-2026-90360, CVE-2026-90361, CVE-2026-90402, CVE-2026-90434, CVE-2026-92501, CVE-2026-93061, CVE-2026-93102, CVE-2026-93103, CVE-2026-93105, CVE-2026-93161, CVE-2026-93188, CVE-2026-93206, CVE-2026-93221, CVE-2026-93226, CVE-2026-93231, CVE-2026-93251, CVE-2026-93268, CVE-2026-93783, CVE-2026-93787, CVE-2026-93790, CVE-2026-93805, CVE-2026-93829, CVE-2026-97422, CVE-2026-97493, CVE-2026-97494, CVE-2026-97496, CVE-2026-97524, CVE-2026-97554, CVE-2026-97561, CVE-2026-97563, CVE-2026-97565, CVE-2026-97573, CVE-2026-97620, CVE-2026-97899, CVE-2026-97929, CVE-2026-97991, CVE-2026-97992, CVE-2026-97993, CVE-2026-98009, CVE-2026-98037, CVE-2026-98074, CVE-2026-98099, CVE-2026-98126, CVE-2026-98127, CVE-2026-98142, CVE-2026-98158, CVE-2026-98172, CVE-2026-98176, CVE-2026-98186, CVE-2026-98208, CVE-2026-98213, CVE-2026-98221, CVE-2026-98231, CVE-2026-98233, CVE-2026-98236, CVE-2026-98241, CVE-2026-98246, CVE-2026-98247, CVE-2026-98287, CVE-2026-98296, CVE-2026-98297, CVE-2026-98299, CVE-2026-98300, CVE-2026-98308, CVE-2026-98328, CVE-2026-98336, CVE-2026-98337, CVE-2026-98340, CVE-2026-98344, CVE-2026-98345, CVE-2026-98362, CVE-2026-98368, CVE-2026-98373, CVE-2026-98393, CVE-2026-98422, CVE-2026-98429, CVE-2026-98441, CVE-2026-98452, CVE-2026-98453, CVE-2026-98455, CVE-2026-98461, CVE-2026-98484, CVE-2026-98495, CVE-2026-98499, CVE-2026-98503, CVE-2026-98507, CVE-2026-98511, CVE-2026-98536, CVE-2026-98550, CVE-2026-98612, CVE-2026-98624, CVE-2026-98640, CVE-2026-98681, CVE-2026-98706, CVE-2026-98752, CVE-2026-98799, CVE-2026-98836, CVE-2026-98850, CVE-2026-98853, CVE-2026-98862, CVE-2026-98936, CVE-2026-98947, CVE-2026-98955, CVE-2026-98984, CVE-2026-99005, CVE-2026-99033, CVE-2026-99112, CVE-2026-99122, CVE-2026-99123, CVE-2026-99128, CVE-2026-99131, CVE-2026-99136, CVE-2026-99176, CVE-2026-99218, CVE-2026-99219, CVE-2026-99222, CVE-2026-99224, CVE-2026-99225, CVE-2026-99226, CVE-2026-99227, CVE-2026-99233, CVE-2026-99235, CVE-2026-99236, CVE-2026-99246, CVE-2026-99270, CVE-2026-99272, CVE-2026-99281, CVE-2026-99283

CLSA: 2026:1794654433