CentOS Linux 8 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞 （CENTOS-STREAM8：CLSA-2026：1792759740）
high Nessus 插件 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 中的指南更新受影响的程序包。另见
插件详情
严重性: 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