CentOS Linux 8.5 [TuxCare] 安全更新：bpftool / kernel / kernel-core / kernel-cross-headers / 等多个漏洞 （CENTOS8.5：CLSA-2026：1791852988）
high Nessus 插件 ID 365299
语言：
简介
CentOS Linux 主机缺少一个或多个安全更新。描述
CentOS Linux 8.5 主机上存在安装的程序包，该程序包受到 TuxCare CENTOS8.5：CLSA-2026：U 1791852988公告中提及的多个漏洞的影响。- 已修复 Linux 内核中的下列漏洞：ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value The return value of acpi_fetch_acpi_dev() could be NULL, which would cause a NULL pointer dereference to occur in acpi_device_hid(). [ rjw: Subject and changelog edits, added empty line after if () ] (CVE-2022-50327)
- 已修复 Linux 内核中的下列漏洞：ext4: fix null-ptr-deref in ext4_write_info I caught a null-ptr-deref bug as follows:
================================================================== KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339 RIP: 0010:ext4_write_info+0x53/0x1b0 [...] Call Trace: dquot_writeback_dquots+0x341/0x9a0 ext4_sync_fs+0x19e/0x800 __sync_filesystem+0x83/0x100 sync_filesystem+0x89/0xf0 generic_shutdown_super+0x79/0x3e0 kill_block_super+0xa1/0x110 deactivate_locked_super+0xac/0x130 deactivate_super+0xb6/0xd0 cleanup_mnt+0x289/0x400 __cleanup_mnt+0x16/0x20 task_work_run+0x11c/0x1c0 exit_to_user_mode_prepare+0x203/0x210 syscall_exit_to_user_mode+0x5b/0x3a0 do_syscall_64+0x59/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ================================================================== Above issue may happen as follows:
------------------------------------- exit_to_user_mode_prepare task_work_run __cleanup_mnt cleanup_mnt deactivate_super deactivate_locked_super kill_block_super generic_shutdown_super shrink_dcache_for_umount dentry = sb->s_root sb->s_root = NULL <--- Here set NULL sync_filesystem __sync_filesystem sb->s_op->sync_fs > ext4_sync_fs dquot_writeback_dquots sb->dq_op->write_info > ext4_write_info ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2) d_inode(sb->s_root) s_root->d_inode <--- Null pointer dereference To solve this problem, we use ext4_journal_start_sb directly to avoid s_root being used. (CVE-2022-50344)
- 已修复 Linux 内核中的下列漏洞：drm/vkms: Fix null-ptr-deref in vkms_release() A null-ptr-deref is triggered when it tries to destroy the workqueue in vkms->output.composer_workq in vkms_release(). KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24 RIP: 0010:destroy_workqueue+0x2f/0x710 ... Call Trace: <TASK> ? vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/0x1000 [vkms] do_one_initcall+0xd0/0x4f0 do_init_module+0x1a4/0x680 load_module+0x6249/0x7110
__do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that an OOM happened which triggers the destroy of the workqueue, however, the workqueue is alloced in the later process, thus a null-ptr-deref happened. A simple call graph is shown as below:
vkms_init() vkms_create() devm_drm_dev_alloc() __devm_drm_dev_alloc() devm_drm_dev_init() devm_add_action_or_reset() devm_add_action() # an error happened devm_drm_dev_init_release() drm_dev_put() kref_put() drm_dev_release() vkms_release() destroy_workqueue() # null-ptr-deref happened vkms_modeset_init() vkms_output_init() vkms_crtc_init() # where the workqueue get allocated Fix this by checking if composer_workq is NULL before passing it to the destroy_workqueue() in vkms_release().
(CVE-2022-50369)
- 已修复 Linux 内核中的下列漏洞：nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure On error situation `clp->cl_cb_conn.cb_xprt` should not be given a reference to the xprt otherwise both client cleanup and the error handling path of the caller call to put it. Better to delay handing over the reference to a later branch. [ 72.530665] refcount_t: underflow; use-after-free. [ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120 [72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc] [ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1 [ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014 [ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd] [ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120 [ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48 [ 72.546666] RSP:
0018:ffffb3f841157cf0 EFLAGS: 00010286 [ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX:
0000000000000000 [ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0 [72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff [ 72.550209] R10:
0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180 [ 72.551142] R13: ffff89ac6231d478 R14:
ffff89ac40c06180 R15: ffff89ac6231d4b0 [ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000 [ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 72.553934] CR2:
0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0 [ 72.554874] Call Trace: [ 72.555278] <TASK> [ 72.555614] svc_xprt_put+0xaf/0xe0 [sunrpc] [ 72.556276] nfsd4_process_cb_update.isra.11+0xb7/0x410 [nfsd] [ 72.557087] ? update_load_avg+0x82/0x610 [ 72.557652] ? cpuacct_charge+0x60/0x70 [ 72.558212] ? dequeue_entity+0xdb/0x3e0 [ 72.558765] ? queued_spin_unlock+0x9/0x20 [ 72.559358] nfsd4_run_cb_work+0xfc/0x270 [nfsd] [ 72.560031] process_one_work+0x1df/0x390 [ 72.560600] worker_thread+0x37/0x3b0 [ 72.561644] ? process_one_work+0x390/0x390 [ 72.562247] kthread+0x12f/0x150 [72.562710] ? set_kthread_struct+0x50/0x50 [ 72.563309] ret_from_fork+0x22/0x30 [ 72.563818] </TASK> [72.564189] ---[ end trace 031117b1c72ec616 ]--- [ 72.566019] list_add corruption. next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018). [ 72.567647] ------------[ cut here ]------------ (CVE-2022-50401)
- 已修复 Linux 内核中的下列漏洞：bpf: Propagate error from htab_lock_bucket() to userspace In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns
-EBUSY, it will go to next bucket. Going to next bucket may not only skip the elements in current bucket silently, but also incur out-of-bound memory access or expose kernel memory to userspace if current bucket_cnt is greater than bucket_size or zero. Fixing it by stopping batch operation and returning -EBUSY when htab_lock_bucket() fails, and the application can retry or skip the busy batch as needed.
(CVE-2022-50490)
请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
根据 TuxCare 公告 CENTOS8.5：CLSA-2026：1791852988 中的指南更新受影响的程序包。另见
插件详情
严重性: High
ID: 365299
文件名: tuxcare_centos_8.5_CLSA-2026-1791852988.nasl
版本: 1.1
类型: Local
代理: unix
发布时间: 2026/10/13
最近更新时间: 2026/10/13
支持的传感器: Nessus Agent, Continuous Assessment, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
风险信息
VPR
风险因素: Critical
分数: 9.3
百分位: 99.82
Vendor
Vendor Severity: Critical
CVSS v2
风险因素: High
基本分数: 7.8
时间分数: 6.4
矢量: CVSS2#AV:N/AC:L/Au:N/C:C/I:N/A:N
CVSS 分数来源: CVE-2023-0045
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
CVSS 分数来源: CVE-2026-64348
CVSS v4
风险因素: High
Base Score: 7.3
Threat Score: 7.3
Threat Vector: CVSS:4.0/E:A
Vector: CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
CVSS 分数来源: CVE-2025-54518
漏洞信息
必需的 KB 项: Host/local_checks_enabled, Host/CentOS/release, Host/CentOS/rpm-list, Host/OS/extended-third-party
可利用: true
易利用性: Exploits are available
补丁发布日期: 2026/10/13
漏洞发布日期: 2021/7/21
CISA 已知可遭利用的漏洞到期日期: 2026/9/21
参考资料信息
CVE: CVE-2022-50327, CVE-2022-50344, CVE-2022-50369, CVE-2022-50401, CVE-2022-50490, CVE-2022-50552, CVE-2023-0045, CVE-2023-3772, CVE-2023-53147, CVE-2023-53272, CVE-2023-53296, CVE-2024-39480, CVE-2025-37913, CVE-2025-37915, CVE-2025-38107, CVE-2025-38108, CVE-2025-38111, CVE-2025-38117, CVE-2025-38146, CVE-2025-38239, CVE-2025-38584, CVE-2025-39790, CVE-2025-39810, CVE-2025-39835, CVE-2025-39860, CVE-2025-39880, CVE-2025-39964, CVE-2025-54518, CVE-2026-100075, CVE-2026-17523, CVE-2026-23318, CVE-2026-23447, CVE-2026-23454, CVE-2026-31399, CVE-2026-31493, CVE-2026-31686, CVE-2026-43049, CVE-2026-43116, CVE-2026-43133, CVE-2026-43329, CVE-2026-43449, CVE-2026-43453, CVE-2026-46174, CVE-2026-52962, CVE-2026-53266, CVE-2026-53352, CVE-2026-63971, CVE-2026-64268, CVE-2026-64304, CVE-2026-64305, CVE-2026-64320, CVE-2026-64322, CVE-2026-64323, CVE-2026-64340, CVE-2026-64341, CVE-2026-64342, CVE-2026-64343, CVE-2026-64344, CVE-2026-64348, CVE-2026-64422, CVE-2026-64423, CVE-2026-64438, CVE-2026-64448, CVE-2026-64496, CVE-2026-64563, CVE-2026-64572, CVE-2026-64579, CVE-2026-68121, CVE-2026-68143, CVE-2026-68153, CVE-2026-68155, CVE-2026-68156, CVE-2026-68158, CVE-2026-68160, CVE-2026-68188, CVE-2026-68214, CVE-2026-68236, CVE-2026-68320, CVE-2026-68363, CVE-2026-68376, CVE-2026-72129, CVE-2026-72389, CVE-2026-74287, CVE-2026-74499, CVE-2026-74556, CVE-2026-74580, CVE-2026-74583, CVE-2026-74587, CVE-2026-74588, CVE-2026-74597, CVE-2026-74630, CVE-2026-74660, CVE-2026-74689, CVE-2026-74705, CVE-2026-74725, CVE-2026-74744, CVE-2026-74752, CVE-2026-80536, CVE-2026-80558, CVE-2026-80576, CVE-2026-80844, CVE-2026-81000, CVE-2026-89555, CVE-2026-90413, CVE-2026-90414, CVE-2026-90435, CVE-2026-97417
CLSA: 2026:1791852988