AlmaLinux 9.6 [TuxCare] 安全性更新：kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc 多個弱點 （ALMALINUX9.6：CLSA-2026：1792762308）
high Nessus Plugin ID 371426
語言:
概要
AlmaLinux 主機缺少一個或多個安全性更新。說明
AlmaLinux 9.6 主機已安裝的套件會受到 TuxCare ALMALINUX9.6：CLSA-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 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 371426
檔案名稱: tuxcare_alma_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/AlmaLinux/release, Host/AlmaLinux/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-80726, 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