Rocky Linux 9.6 [TuxCare] 安全更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞 （ALMALINUX9.6：CLSA-2026：1792762308）
high Nessus 插件 ID 371428
语言：
简介
Rocky Linux 主机缺少一个或多个安全更新。描述
Rocky Linux 9.6 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.6：CLSA-2026：2026：1792762308公告中提及的多个漏洞的影响。- 已修复 Linux 内核中的下列漏洞：scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable. (CVE-2025-37861)
- 已修复 Linux 内核中的下列漏洞：Bluetooth: MGMT: cancel mesh send timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT timers. Should fix the BUG: sporadically seen by BlueZ test bot (in Mesh - Send cancel - 1 test). Log:
------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36:
kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60
__kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------ (CVE-2025-40284)
- 已修复 Linux 内核中的下列漏洞：ASoC: Intel: avs: Disable periods-elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two operations shall be synchronized to avoid slab-use-after-free or worse errors. (CVE-2025-40344)
- 已修复 Linux 内核中的下列漏洞：ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach() Sashiko AI-review observed: In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2). IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm.
The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18. If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO). This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao. Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info? Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this? This patch implements the first suggestion. I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway. (CVE-2026-43038)
- 已修复 Linux 内核中的下列漏洞：RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this:
kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user. (CVE-2026-45852)
请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
根据 TuxCare 公告 ALMALINUX9.6：CLSA-2026：1792762308 中的指南更新受影响的程序包。另见
插件详情
严重性: High
ID: 371428
文件名: tuxcare_rocky_linux_9.6_CLSA-2026-1792762308.nasl
版本: 1.1
类型: Local
发布时间: 2026/10/23
最近更新时间: 2026/10/23
支持的传感器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
风险信息
VPR
风险因素: High
分数: 7.9
百分位: 99.34
Vendor
Vendor Severity: Critical
CVSS v2
风险因素: Medium
基本分数: 6.8
时间分数: 5.3
矢量: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C
CVSS 分数来源: CVE-2026-63794
CVSS v3
风险因素: High
基本分数: 7.8
时间分数: 7
矢量: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
时间矢量: CVSS:3.0/E:P/RL:O/RC:C
漏洞信息
必需的 KB 项: Host/local_checks_enabled, Host/cpu, Host/RockyLinux/release, Host/RockyLinux/rpm-list, Host/OS/extended-third-party
可利用: true
易利用性: Exploits are available
补丁发布日期: 2026/10/23
漏洞发布日期: 2025/5/9
参考资料信息
CVE: CVE-2025-37861, CVE-2025-40284, CVE-2025-40344, CVE-2026-43038, CVE-2026-45852, CVE-2026-45857, CVE-2026-45861, CVE-2026-45898, CVE-2026-45957, CVE-2026-45984, CVE-2026-46120, CVE-2026-46150, CVE-2026-46155, CVE-2026-46209, CVE-2026-46227, CVE-2026-46266, CVE-2026-46323, CVE-2026-46324, CVE-2026-52951, CVE-2026-52956, CVE-2026-52998, CVE-2026-53004, CVE-2026-53006, CVE-2026-53059, CVE-2026-53078, CVE-2026-53089, CVE-2026-53129, CVE-2026-53185, CVE-2026-53203, CVE-2026-53228, CVE-2026-53230, CVE-2026-53242, CVE-2026-53275, CVE-2026-53398, CVE-2026-63794, CVE-2026-63887, CVE-2026-64002, CVE-2026-64007, CVE-2026-64015, CVE-2026-64121, CVE-2026-64189, CVE-2026-64378, CVE-2026-68176, CVE-2026-68201, CVE-2026-68236, CVE-2026-68405, CVE-2026-72029, CVE-2026-72157, CVE-2026-72261, CVE-2026-72402, CVE-2026-72413, CVE-2026-72469, CVE-2026-74287, CVE-2026-74289, CVE-2026-74387, CVE-2026-74390, CVE-2026-74394, CVE-2026-74408, CVE-2026-74444, CVE-2026-74469, CVE-2026-74470, CVE-2026-74480, CVE-2026-74498, CVE-2026-74518, CVE-2026-74569, CVE-2026-74581, CVE-2026-80613, CVE-2026-89448, CVE-2026-89478, CVE-2026-89508, CVE-2026-89533, CVE-2026-89542, CVE-2026-89550, CVE-2026-89553, CVE-2026-89559, CVE-2026-89575, CVE-2026-89671, CVE-2026-89690, CVE-2026-89699, CVE-2026-89712, CVE-2026-89729, CVE-2026-89786, CVE-2026-89847, CVE-2026-89932, CVE-2026-89965, CVE-2026-90000, CVE-2026-90033, CVE-2026-90067, CVE-2026-90103, CVE-2026-90203, CVE-2026-90228, CVE-2026-90334, CVE-2026-90335, CVE-2026-90382, CVE-2026-90383, CVE-2026-90393, CVE-2026-90413, CVE-2026-90414, CVE-2026-93054, CVE-2026-93262, CVE-2026-93791, CVE-2026-93822, CVE-2026-93826, CVE-2026-93830, CVE-2026-97427, CVE-2026-97448, CVE-2026-97509, CVE-2026-97539, CVE-2026-97564, CVE-2026-97596, CVE-2026-97612, CVE-2026-97940, CVE-2026-98015, CVE-2026-98025, CVE-2026-98041, CVE-2026-98066, CVE-2026-98077, CVE-2026-98130, CVE-2026-98175, CVE-2026-98185, CVE-2026-98196, CVE-2026-98217, CVE-2026-98264, CVE-2026-98276, CVE-2026-98374, CVE-2026-98375, CVE-2026-98383
CLSA: 2026:1792762308