CentOS Linux 8 [TuxCare] 安全性更新：bpftool / kernel / kernel-core / kernel-cross-headers / etc 多個漏洞 （CENTOS-STREAM8：CLSA-2026：1792759740）
high Nessus Plugin ID 371420
語言:
概要
CentOS Linux 主機缺少一個或多個安全性更新。說明
CentOS Linux 8 主機已安裝的套件受到 TuxCare CENTOS-STREAM8：CLSA-2026：1792759740 公告中提及的多個弱點影響。- 已解決 Linux 核心中的下列弱點：mrp: introduce active flags to prevent UAF when applicant uninit The caller of del_timer_sync must prevent restarting of the timer, If we have no this synchronization, there is a small probability that the cancellation will not be successful. And syzbot report the fellowing crash: ================================================================== BUG:
KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline] BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 Write at addr f9ff000024df6058 by task syz-fuzzer/2256 Pointer tag: [f9], memory tag: [fe] CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008- ge01d50cbd6ee #0 Hardware name: linux,dummy-virt (DT) Call trace:
dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163
__dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395 kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320 do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749 do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367 el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627 call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4 kernel/time/timer.c:1519 To fix it, we can introduce a new active flags to make sure the timer will not restart. (CVE-2022-50697)
- 已解決 Linux 核心中的下列弱點：ubi: Fix use-after-free when volume resizing failed There is an use-after-free problem reported by KASAN:
================================================================== BUG: KASAN: use-after-free in ubi_eba_copy_table+0x11f/0x1c0 [ubi] Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735 CPU: 2 PID: 4735 Comm: ubirsvol Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 ubi_eba_copy_table+0x11f/0x1c0 [ubi] ubi_resize_volume+0x4f9/0xbc0 [ubi] ubi_cdev_ioctl+0x701/0x1850 [ubi] __x64_sys_ioctl+0x11d/0x170 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> When ubi_change_vtbl_record() returns an error in ubi_resize_volume(), new_eba_tbl will be freed on error handing path, but it is holded by vol->eba_tbl in ubi_eba_replace_table(). It means that the liftcycle of vol->eba_tbl and vol are different, so when resizing volume in next time, it causing an use-after-free fault. Fix it by not freeing new_eba_tbl after it replaced in ubi_eba_replace_table(), while will be freed in next volume resizing. (CVE-2023-53800)
- 已解決 Linux 核心中的下列弱點：RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).
(CVE-2026-45856)
- 已解決 Linux 核心中的下列弱點：gfs2: Fix slab-use-after-free in qd_put Commit a475c5dd16e5 (gfs2: Free quota data objects synchronously) started freeing quota data objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access already-freed objects on the LRU list. Fix this by removing qd objects from the LRU list before freeing them in qd_put(). Initial fix from Deepanshu Kartikey <[email protected]>. (CVE-2026-45861)
- 已解決 Linux 核心中的下列弱點：gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2.
Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().] (CVE-2026-45984)
請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
根據 TuxCare 公告 CENTOS-STREAM8：CLSA-2026：1792759740 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: High
ID: 371420
檔案名稱: tuxcare_centos_8_CLSA-2026-1792759740.nasl
版本: 1.1
類型: Local
代理程式: unix
已發布: 2026/10/23
已更新: 2026/10/23
支援的感應器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
風險資訊
VPR
風險因素: Critical
分數: 9.2
百分位數: 99.77
Vendor
Vendor Severity: Critical
CVSS v2
風險因素: Medium
基本分數: 6.8
時間性分數: 5.6
媒介: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C
CVSS 評分資料來源: CVE-2026-64362
CVSS v3
風險因素: High
基本分數: 7.8
時間性分數: 7.2
媒介: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:F/RL:O/RC:C
弱點資訊
必要的 KB 項目: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/OS/extended-third-party
可被惡意程式利用: true
可輕鬆利用: Exploits are available
修補程式發佈日期: 2026/10/23
弱點發布日期: 2021/7/21
參考資訊
CVE: CVE-2022-50697, CVE-2023-53800, CVE-2026-43503, CVE-2026-45856, CVE-2026-45861, CVE-2026-45970, CVE-2026-45984, CVE-2026-46043, CVE-2026-46047, CVE-2026-46056, CVE-2026-46119, CVE-2026-46120, CVE-2026-46133, CVE-2026-46149, CVE-2026-46180, CVE-2026-46181, CVE-2026-46189, CVE-2026-46209, CVE-2026-46227, CVE-2026-46259, CVE-2026-46294, CVE-2026-52912, CVE-2026-52920, CVE-2026-52923, CVE-2026-52924, CVE-2026-52935, CVE-2026-52942, CVE-2026-52947, CVE-2026-52957, CVE-2026-52986, CVE-2026-52993, CVE-2026-53002, CVE-2026-53004, CVE-2026-53006, CVE-2026-53016, CVE-2026-53059, CVE-2026-53062, CVE-2026-53071, CVE-2026-53075, CVE-2026-53078, CVE-2026-53089, CVE-2026-53131, CVE-2026-53136, CVE-2026-53148, CVE-2026-53149, CVE-2026-53182, CVE-2026-53195, CVE-2026-53223, CVE-2026-53228, CVE-2026-53239, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256, CVE-2026-53264, CVE-2026-53265, CVE-2026-53268, CVE-2026-53270, CVE-2026-53374, CVE-2026-53391, CVE-2026-53397, CVE-2026-63794, CVE-2026-63800, CVE-2026-63801, CVE-2026-63886, CVE-2026-63887, CVE-2026-63892, CVE-2026-63922, CVE-2026-63975, CVE-2026-63992, CVE-2026-63994, CVE-2026-64002, CVE-2026-64007, CVE-2026-64009, CVE-2026-64015, CVE-2026-64018, CVE-2026-64047, CVE-2026-64102, CVE-2026-64113, CVE-2026-64114, CVE-2026-64115, CVE-2026-64189, CVE-2026-64191, CVE-2026-64276, CVE-2026-64277, CVE-2026-64320, CVE-2026-64351, CVE-2026-64362, CVE-2026-64546, CVE-2026-64548, CVE-2026-72157, CVE-2026-72262, CVE-2026-74287, CVE-2026-74377, CVE-2026-74480, CVE-2026-74581, CVE-2026-80714, CVE-2026-89537, CVE-2026-89569, CVE-2026-89575, CVE-2026-89655, CVE-2026-89656, CVE-2026-89699, CVE-2026-89729, CVE-2026-89786, CVE-2026-89823, CVE-2026-89854, CVE-2026-89856, CVE-2026-89861, CVE-2026-89893, CVE-2026-89932, CVE-2026-89965, CVE-2026-90000, CVE-2026-90011, CVE-2026-90033, CVE-2026-90103, CVE-2026-90203, CVE-2026-90334, CVE-2026-90335, CVE-2026-90382, CVE-2026-90413, CVE-2026-90414, CVE-2026-90435, CVE-2026-93054, CVE-2026-93262, CVE-2026-93791, CVE-2026-98025, CVE-2026-98116, CVE-2026-98130, CVE-2026-98185, CVE-2026-98222, CVE-2026-98323, CVE-2026-98343, CVE-2026-98360, CVE-2026-98375
CLSA: 2026:1792759740