CentOS Linux 7 [TuxCare] 安全更新:bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / 等多个漏洞 (CENTOS7:CLSA-2026:1775657929)

high Nessus 插件 ID 361381

简介

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

描述

如 TuxCare CENTOS7:CLSA-2026:1775657929公告所述,CentOS Linux 7 主机上存在安装的程序包,该漏洞会受到多个漏洞的影响。

- 已修复 Linux 内核中的下列漏洞:ovl: Filter invalid inodes with missing lookup function Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack. (CVE-2024-56570)

- 已修复 Linux 内核中的下列漏洞:NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode
-> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout. (CVE-2025-68349)

- 已修复 Linux 内核中的下列漏洞:net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim <[email protected]> managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ) class 1:1 (weight=15, lmax=16384) netem with delay 6.4s class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF. (CVE-2026-23074)

- 已修复 Linux 内核中的下列漏洞:ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace:
get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element. (CVE-2026-23089)

- 已修复 Linux 内核中的下列漏洞:ALSA: aloop: Fix racy access at PCM trigger The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF. (CVE-2026-23191)

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

解决方案

根据 TuxCare 公告 CENTOS7:CLSA-2026:1775657929 中的指南更新受影响的程序包。

另见

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

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

插件详情

严重性: High

ID: 361381

文件名: tuxcare_centos_7_CLSA-2026-1775657929.nasl

版本: 1.1

类型: Local

代理: unix

发布时间: 2026/10/1

最近更新时间: 2026/10/1

支持的传感器: Continuous Assessment, Nessus Agent, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus

风险信息

VPR

风险因素: Medium

分数: 6.9

百分位: 97.08

Vendor

Vendor Severity: Important

CVSS v2

风险因素: Medium

基本分数: 6.8

时间分数: 5

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

CVSS 分数来源: CVE-2026-23193

CVSS v3

风险因素: High

基本分数: 7.8

时间分数: 6.8

矢量: CVSS:3.0/AV:L/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/CentOS/release, Host/CentOS/rpm-list

易利用性: No known exploits are available

补丁发布日期: 2026/4/8

漏洞发布日期: 2023/12/12

参考资料信息

CVE: CVE-2024-56570, CVE-2025-68349, CVE-2026-23074, CVE-2026-23089, CVE-2026-23191, CVE-2026-23193, CVE-2026-23204

CLSA: 2026:1775657929