AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc多個弱點 （ALMALINUX9.2：CLSA-2026：1779987841）
high Nessus Plugin ID 360748
語言:
概要
AlmaLinux 主機缺少一或多個安全性更新。說明
AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1779987841 公告中提及的多個弱點影響。- 已解決 Linux 核心中的下列弱點：net: hns3: do not allow call hns3_nic_net_open repeatedly hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc :
napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27:
ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20:
0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16:
ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12:
0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 :
0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 :
0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napi_enable+0x80/0x84 [3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] process_one_work+0x1dc/0x48c [ 3078.481888] worker_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]--- Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set.
(CVE-2021-47400)
- 已解決 Linux 核心中的下列弱點：can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() Using wait_event_interruptible() to wait for complete transmission, but do not check the result of wait_event_interruptible() which can be interrupted. It will result in TX buffer has multiple accessors and the later process interferes with the previous process.
Following is one of the problems reported by syzbot.
============================================================= WARNING: CPU: 0 PID: 0 at net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc7+ #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0 Call Trace: <IRQ> ? isotp_setsockopt+0x390/0x390
__hrtimer_run_queues+0xb8/0x610 hrtimer_run_softirq+0x91/0xd0 ? rcu_read_lock_sched_held+0x4d/0x80
__do_softirq+0xe8/0x553 irq_exit_rcu+0xf8/0x100 sysvec_apic_timer_interrupt+0x9e/0xc0 </IRQ> asm_sysvec_apic_timer_interrupt+0x12/0x20 Add result check for wait_event_interruptible() in isotp_sendmsg() to avoid multiple accessers for tx buffer. (CVE-2021-47457)
- 已解決 Linux 核心中的下列弱點：serial: core: fix transmit-buffer reset and memleak Commit 761ed4a94582 (tty: serial_core: convert uart_close to use tty_port_close) converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e (uart: fix race between uart_put_char() and uart_shutdown()). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace (tty/serial: do not free trasnmit buffer page under port lock)). (CVE-2021-47527)
- 已解決 Linux 核心中的下列弱點：mm/gup: fix gup_pud_range() for dax For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured.
However, dax doesn't depend on hugetlb. Commit 414fd080d125 (mm/gup: fix gup_pmd_range() for dax) fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: <TASK> get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30
__generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100
__x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > </TASK>
---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Kernel panic - not syncing: Fatal exception Kernel Offset: disabled (CVE-2022-48986)
- 已解決 Linux 核心中的下列弱點：lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/[email protected]/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/[email protected]/ (CVE-2022-49078)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
根據 TuxCare 公告 ALMALINUX9.2：CLSA-2026：1779987841 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 360748
檔案名稱: tuxcare_alma_linux_9.2_CLSA-2026-1779987841.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.6
百分位數: 98.25
Vendor
Vendor Severity: Important
CVSS v2
風險因素: High
基本分數: 7.7
時間性分數: 5.7
媒介: CVSS2#AV:A/AC:L/Au:S/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2022-50386
CVSS v3
風險因素: High
基本分數: 8
時間性分數: 7
媒介: CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:U/RL:O/RC:C
弱點資訊
必要的 KB 項目: Host/OS/extended-third-party, Host/local_checks_enabled, Host/AlmaLinux/release, Host/AlmaLinux/rpm-list, Host/cpu
可輕鬆利用: No known exploits are available
修補程式發佈日期: 2026/5/28
弱點發布日期: 2021/7/21
參考資訊
CVE: CVE-2021-47400, CVE-2021-47457, CVE-2021-47527, CVE-2022-48754, CVE-2022-48899, CVE-2022-48986, CVE-2022-49078, CVE-2022-49220, CVE-2022-49257, CVE-2022-49273, CVE-2022-50277, CVE-2022-50297, CVE-2022-50372, CVE-2022-50374, CVE-2022-50386, CVE-2022-50391, CVE-2022-50491, CVE-2022-50535, CVE-2023-52492, CVE-2023-52529, CVE-2023-52610, CVE-2023-52676, CVE-2023-52698, CVE-2023-52730, CVE-2023-52791, CVE-2023-52800, CVE-2023-52813, CVE-2023-52832, CVE-2023-52881, CVE-2023-53006, CVE-2023-53010, CVE-2023-53038, CVE-2023-53042, CVE-2023-53168, CVE-2023-53197, CVE-2023-53202, CVE-2023-53288, CVE-2023-53359, CVE-2023-53390, CVE-2023-53409, CVE-2023-53437, CVE-2023-53451, CVE-2023-53476, CVE-2023-53577, CVE-2023-53585, CVE-2023-53594, CVE-2023-53613, CVE-2023-53615, CVE-2023-53641, CVE-2023-53669, CVE-2023-53726, CVE-2024-26803, CVE-2024-26846, CVE-2024-26894, CVE-2024-26924, CVE-2024-26937, CVE-2024-26950, CVE-2024-26984, CVE-2024-27038, CVE-2024-27393, CVE-2024-27410, CVE-2024-27431, CVE-2024-35801, CVE-2024-35805, CVE-2024-35809, CVE-2024-35817, CVE-2024-35838, CVE-2024-35854, CVE-2024-35908, CVE-2024-35912, CVE-2024-35938, CVE-2024-35944, CVE-2024-35947, CVE-2024-35960, CVE-2024-36006, CVE-2024-36905, CVE-2024-36955, CVE-2024-36957, CVE-2024-38605, CVE-2024-38615, CVE-2024-39276, CVE-2024-40923, CVE-2024-41031, CVE-2024-42076, CVE-2024-42080, CVE-2024-42265, CVE-2024-42321, CVE-2024-43863, CVE-2024-49881, CVE-2024-49907, CVE-2024-49929, CVE-2024-53164, CVE-2024-53194, CVE-2024-56644, CVE-2025-21653, CVE-2025-21796, CVE-2026-23011, CVE-2026-23243, CVE-2026-23270, CVE-2026-31402, CVE-2026-31415, CVE-2026-31427, CVE-2026-31428, CVE-2026-31452, CVE-2026-31686, CVE-2026-31759, CVE-2026-43049, CVE-2026-43052, CVE-2026-43427
CLSA: 2026:1779987841