AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點 （ALMALINUX9.2：CLSA-2026：1771239384）
high Nessus Plugin ID 360081
語言:
概要
AlmaLinux 主機缺少一或多個安全性更新。說明
AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1771239384 公告中提及的多個弱點影響。- 已解決 Linux 核心中的下列弱點：block, bfq: fix uaf for bfqq in bfq_exit_icq_bfqq Commit 64dc8c732f5c (block, bfq: fix possible uaf for 'bfqq->bic') will access 'bic->bfqq' in bic_set_bfqq(), however, bfq_exit_icq_bfqq() can free bfqq first, and then call bic_set_bfqq(), which will cause uaf. Fix the problem by moving bfq_exit_bfqq() behind bic_set_bfqq().
(CVE-2022-50329)
- 已解決 Linux 核心中的下列弱點：block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10:
================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace:
bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0
__blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0
__blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90
__iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d (bfq: Split shared queues on move between cgroups) changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | | | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic. (CVE-2022-50488)
- 已解決 Linux 核心中的下列弱點：wifi: ath10k: Delay the unmapping of the buffer On WCN3990, we are seeing a rare scenario where copy engine hardware is sending a copy complete interrupt to the host driver while still processing the buffer that the driver has sent, this is leading into an SMMU fault triggering kernel panic. This is happening on copy engine channel 3 (CE3) where the driver normally enqueues WMI commands to the firmware. Upon receiving a copy complete interrupt, host driver will immediately unmap and frees the buffer presuming that hardware has processed the buffer. In the issue case, upon receiving copy complete interrupt, host driver will unmap and free the buffer but since hardware is still accessing the buffer (which in this case got unmapped in parallel), SMMU hardware will trigger an SMMU fault resulting in a kernel panic. In order to avoid this, as a work around, add a delay before unmapping the copy engine source DMA buffer. This is conditionally done for WCN3990 and only for the CE3 channel where issue is seen. Below is the crash signature: wifi smmu error: kernel: [10.120965] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fdfd8ac0, fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandled context fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003, cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal error received: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091: cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149 remoteproc remoteproc0: crash detected in 4080000.remoteproc: type fatal error <3> remoteproc remoteproc0: handling crash #1 in 4080000.remoteproc pc :
__arm_lpae_unmap+0x500/0x514 lr : __arm_lpae_unmap+0x4bc/0x514 sp : ffffffc011ffb530 x29: ffffffc011ffb590 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000004 x25: 0000000000000003 x24:
ffffffc011ffb890 x23: ffffffa762ef9be0 x22: ffffffa77244ef00 x21: 0000000000000009 x20: 00000007fff7c000 x19: 0000000000000003 x18: 0000000000000000 x17: 0000000000000004 x16: ffffffd7a357d9f0 x15:
0000000000000000 x14: 00fd5d4fa7ffffff x13: 000000000000000e x12: 0000000000000000 x11: 00000000ffffffff x10: 00000000fffffe00 x9 : 000000000000017c x8 : 000000000000000c x7 : 0000000000000000 x6 :
ffffffa762ef9000 x5 : 0000000000000003 x4 : 0000000000000004 x3 : 0000000000001000 x2 : 00000007fff7c000 x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace: __arm_lpae_unmap+0x500/0x514
__arm_lpae_unmap+0x4bc/0x514 __arm_lpae_unmap+0x4bc/0x514 arm_lpae_unmap_pages+0x78/0xa4 arm_smmu_unmap_pages+0x78/0x104 __iommu_unmap+0xc8/0x1e4 iommu_unmap_fast+0x38/0x48
__iommu_dma_unmap+0x84/0x104 iommu_dma_free+0x34/0x50 dma_free_attrs+0xa4/0xd0 ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c [ath10k_core] ath10k_halt+0x11c/0x180 [ath10k_core] ath10k_stop+0x54/0x94 [ath10k_core] drv_stop+0x48/0x1c8 [mac80211] ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c [mac80211] __dev_open+0xb4/0x174
__dev_change_flags+0xc4/0x1dc dev_change_flags+0x3c/0x7c devinet_ioctl+0x2b4/0x580 inet_ioctl+0xb0/0x1b4 sock_do_ioctl+0x4c/0x16c compat_ifreq_ioctl+0x1cc/0x35c compat_sock_ioctl+0x110/0x2ac
__arm64_compat_sys_ioctl+0xf4/0x3e0 el0_svc_common+0xb4/0x17c el0_svc_compat_handler+0x2c/0x58 el0_svc_compat+0x8/0x2c Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 (CVE-2022-50700)
- 已解決 Linux 核心中的下列弱點：tcp: fix a signed-integer-overflow bug in tcp_add_backlog() The type of sk_rcvbuf and sk_sndbuf in struct sock is int, and in tcp_add_backlog(), the variable limit is caculated by adding sk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max value of int and overflow. This patch reduces the limit budget by halving the sndbuf to solve this issue since ACK packets are much smaller than the payload. (CVE-2022-50865)
- 已解決 Linux 核心中的下列弱點：block, bfq: fix uaf for bfqq in bic_set_bfqq() After commit 64dc8c732f5c (block, bfq: fix possible uaf for 'bfqq->bic'), bic->bfqq will be accessed in bic_set_bfqq(), however, in some context bic->bfqq will be freed, and bic_set_bfqq() is called with the freed bic->bfqq. Fix the problem by always freeing bfqq after bic_set_bfqq().
(CVE-2023-52983)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
根據 TuxCare 公告 ALMALINUX9.2：CLSA-2026：1771239384 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 360081
檔案名稱: tuxcare_alma_linux_9.2_CLSA-2026-1771239384.nasl
版本: 1.1
類型: Local
已發布: 2026/10/1
已更新: 2026/10/1
支援的感應器: Continuous Assessment, Nessus Agent, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
風險資訊
VPR
風險因素: High
分數: 7.9
百分位數: 99.35
Vendor
Vendor Severity: Important
CVSS v2
風險因素: Medium
基本分數: 6.8
時間性分數: 5.3
媒介: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2025-39911
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/OS/extended-third-party, Host/local_checks_enabled, Host/AlmaLinux/release, Host/AlmaLinux/rpm-list, Host/cpu
可被惡意程式利用: true
可輕鬆利用: Exploits are available
修補程式發佈日期: 2026/2/16
弱點發布日期: 2021/7/21
參考資訊
CVE: CVE-2022-50329, CVE-2022-50488, CVE-2022-50700, CVE-2022-50865, CVE-2023-52983, CVE-2023-53259, CVE-2023-53473, CVE-2023-53484, CVE-2023-53668, CVE-2023-53676, CVE-2023-53680, CVE-2023-53762, CVE-2023-53780, CVE-2023-53996, CVE-2023-54015, CVE-2023-54072, CVE-2023-54102, CVE-2023-54155, CVE-2024-58013, CVE-2025-37825, CVE-2025-38004, CVE-2025-38013, CVE-2025-38051, CVE-2025-38083, CVE-2025-38102, CVE-2025-38103, CVE-2025-38107, CVE-2025-38108, CVE-2025-38111, CVE-2025-38118, CVE-2025-38129, CVE-2025-38157, CVE-2025-38180, CVE-2025-38212, CVE-2025-38245, CVE-2025-38320, CVE-2025-38323, CVE-2025-38346, CVE-2025-38375, CVE-2025-38395, CVE-2025-38403, CVE-2025-38415, CVE-2025-38425, CVE-2025-38572, CVE-2025-38574, CVE-2025-38680, CVE-2025-38685, CVE-2025-38702, CVE-2025-38729, CVE-2025-39689, CVE-2025-39691, CVE-2025-39749, CVE-2025-39766, CVE-2025-39790, CVE-2025-39823, CVE-2025-39853, CVE-2025-39863, CVE-2025-39880, CVE-2025-39883, CVE-2025-39891, CVE-2025-39901, CVE-2025-39905, CVE-2025-39911, CVE-2025-39933, CVE-2025-39973, CVE-2025-40141, CVE-2025-40154, CVE-2025-40240, CVE-2025-40248, CVE-2025-40258, CVE-2025-40269, CVE-2025-40271, CVE-2025-40277, CVE-2025-68285, CVE-2025-68305, CVE-2025-68325
CLSA: 2026:1771239384