CentOS Linux 8.5 [TuxCare] 安全更新:bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞 (CENTOS8.5:CLSA-2026:1792750763)

high Nessus 插件 ID 371224

简介

CentOS Linux 主机缺少一个或多个安全更新。

描述

如 TuxCare CENTOS8.5:CLSA-2026:1792750763公告所述,CentOS Linux 8.5 主机上安装的程序包受到多个漏洞的影响。

- 已修复 Linux 内核中的下列漏洞:RDMA: Fix use-after-free in rxe_queue_cleanup On error handling path in rxe_qp_from_init() qp->sq.queue is freed and then rxe_create_qp() will drop last reference to this object. qp clean up function will try to free this queue one time and it causes UAF bug. Fix it by zeroing queue pointer after freeing queue in rxe_qp_from_init().
(CVE-2021-47616)

- 已修复 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 内核中的下列漏洞:mm/khugepaged: fix ->anon_vma race If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires it to be locked. Page table traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached, but does this check before holding the mmap lock (as the comment above the check explains). If we racily merged an existing ->anon_vma (shared with a child process) from a neighboring VMA, subsequent rmap traversals on pages belonging to the child will be able to see the page tables that we are concurrently removing while assuming that nothing else can access them. Repeat the ->anon_vma check once we hold the mmap lock to ensure that there really is no concurrent page table access. Hitting this bug causes a lockdep warning in collapse_and_free_pmd(), in the line lockdep_assert_held_write(&vma->anon_vma->root->rwsem). It can also lead to use-after-free access.
(CVE-2023-52935)

- 已修复 Linux 内核中的下列漏洞:SUNRPC: make sure cache entry active before cache_show The function `c_show` was called with protection from RCU. This only ensures that `cp` will not be freed. Therefore, the reference count for `cp` can drop to zero, which will trigger a refcount use-after-free warning when `cache_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `cp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free.
WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Call Trace: <TASK> c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e (CVE-2024-53174)

- 已修复 Linux 内核中的下列漏洞:net: skbuff: propagate shared-frag marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker.
(CVE-2026-43503)

请注意,Nessus 尚未测试这些问题,而是只依据应用程序自我报告的版本号进行判断。

解决方案

根据 TuxCare 公告 CENTOS8.5:CLSA-2026:1792750763 中的指南更新受影响的程序包。

另见

https://cve.tuxcare.com/els/releases/CLSA-2026:1792750763

http://www.nessus.org/u?a85b9a79

插件详情

严重性: High

ID: 371224

文件名: tuxcare_centos_8.5_CLSA-2026-1792750763.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: Important

CVSS v2

风险因素: Medium

基本分数: 6.8

时间分数: 5.6

矢量: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C

CVSS 分数来源: CVE-2026-63794

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-2021-47616, CVE-2022-50697, CVE-2023-52935, CVE-2024-53174, CVE-2026-43503, CVE-2026-45856, CVE-2026-46033, CVE-2026-46043, CVE-2026-46056, CVE-2026-46120, CVE-2026-46133, CVE-2026-46149, CVE-2026-46189, CVE-2026-46331, CVE-2026-52920, CVE-2026-52956, CVE-2026-52957, CVE-2026-53004, CVE-2026-53006, CVE-2026-53009, CVE-2026-53016, CVE-2026-53059, CVE-2026-53071, CVE-2026-53072, CVE-2026-53075, CVE-2026-53129, CVE-2026-53149, CVE-2026-53195, CVE-2026-53223, CVE-2026-53228, CVE-2026-53268, CVE-2026-53270, CVE-2026-53275, CVE-2026-63794, CVE-2026-63922, CVE-2026-64002, CVE-2026-64009, CVE-2026-64018, CVE-2026-64034, CVE-2026-64047, CVE-2026-64189, CVE-2026-64276, CVE-2026-64380, CVE-2026-64471, CVE-2026-64483, CVE-2026-72157, CVE-2026-72383, CVE-2026-72476, CVE-2026-74255, CVE-2026-74282, CVE-2026-74408, CVE-2026-74444, CVE-2026-74480, CVE-2026-74498, CVE-2026-74540, CVE-2026-74581, CVE-2026-80681, CVE-2026-80714, CVE-2026-89537, CVE-2026-89542, CVE-2026-89548, CVE-2026-89550, CVE-2026-89553, CVE-2026-89575, CVE-2026-89656, CVE-2026-89699, CVE-2026-89729, CVE-2026-89778, CVE-2026-89823, CVE-2026-89856, CVE-2026-89893, CVE-2026-89932, CVE-2026-90033, CVE-2026-90329, CVE-2026-93104, CVE-2026-93175, CVE-2026-93817, CVE-2026-97408, CVE-2026-97427, CVE-2026-97448, CVE-2026-97539, CVE-2026-97612, CVE-2026-97940, CVE-2026-97949, CVE-2026-98017, CVE-2026-98096, CVE-2026-98130, CVE-2026-98217, CVE-2026-98222, CVE-2026-98343, CVE-2026-98364

CLSA: 2026:1792750763