AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞 （ALMALINUX9.2：CLSA-2025：1738671431）
high Nessus 插件 ID 352744
语言：
简介
AlmaLinux 主机缺少一个或多个安全更新。描述
AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2025：1738671431公告中提及的多个漏洞的影响。- 已修复 Linux 内核中的下列漏洞：memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 (memcg: remove cgroup_event->cft), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in
__file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type. (CVE-2022-48988)
- 已修复 Linux 内核中的下列漏洞：Input: powermate - fix use-after-free in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct.
When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e(CVE-2023-52475)
- 已修复 Linux 内核中的下列漏洞：x86/alternatives: Disable KASAN in apply_alternatives() Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine: BUG: KASAN: out-of-bounds in rcu_is_watching() Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0 ... __asan_load4() rcu_is_watching() trace_hardirqs_on() text_poke_early() apply_alternatives() ... On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled(). KASAN gets confused when apply_alternatives() patches the KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing
__VIRTUAL_MASK_SHIFT with 56, works around the issue. Fix it for real by disabling KASAN while the kernel is patching alternatives. [ mingo: updated the changelog ] (CVE-2023-52504)
- 已修复 Linux 内核中的下列漏洞：HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit The EHL (Elkhart Lake) based platforms provide a OOB (Out of band) service, which allows to wakup device when the system is in S5 (Soft-Off state). This OOB service can be enabled/disabled from BIOS settings. When enabled, the ISH device gets PME wake capability. To enable PME wakeup, driver also needs to enable ACPI GPE bit. On resume, BIOS will clear the wakeup bit. So driver need to re-enable it in resume function to keep the next wakeup capability. But this BIOS clearing of wakeup bit doesn't decrement internal OS GPE reference count, so this reenabling on every resume will cause reference count to overflow. So first disable and reenable ACPI GPE bit using acpi_disable_gpe(). (CVE-2023-52519)
- 已修复 Linux 内核中的下列漏洞：wifi: iwlwifi: mvm: Fix a memory corruption issue A few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate) 'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine. At the end of this structure, there is the 'channels' flex array. Each element is of type 'struct ieee80211_channel'. So only 1 element is allocated in this array. When doing:
mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the 'channels' flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void
*)((u8 *)mvm->nvm_data->channels + 1); because of the (u8 *) cast, we add only 1 to the address of the beginning of the flex array. It is likely that we want point at the 'struct ieee80211_rate' allocated just after. Remove the spurious casting so that the pointer arithmetic works as expected. (CVE-2023-52531)
请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
根据 TuxCare 公告 ALMALINUX9.2：CLSA-2025：1738671431 中的指南更新受影响的程序包。另见
插件详情
严重性: High
ID: 352744
文件名: tuxcare_alma_linux_9.2_CLSA-2025-1738671431.nasl
版本: 1.1
类型: Local
发布时间: 2026/9/30
最近更新时间: 2026/9/30
支持的传感器: Continuous Assessment, Nessus Agent, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
风险信息
VPR
风险因素: High
分数: 8.9
百分位: 99.7
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-2024-56708
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/OS/extended-third-party, Host/local_checks_enabled, Host/AlmaLinux/release, Host/AlmaLinux/rpm-list, Host/cpu
可利用: true
易利用性: Exploits are available
补丁发布日期: 2025/2/4
漏洞发布日期: 2021/7/21
CISA 已知可遭利用的漏洞到期日期: 2025/4/30
参考资料信息
CVE: CVE-2022-48988, CVE-2023-52475, CVE-2023-52504, CVE-2023-52519, CVE-2023-52531, CVE-2023-52614, CVE-2023-52818, CVE-2024-26689, CVE-2024-26754, CVE-2024-27043, CVE-2024-35861, CVE-2024-35868, CVE-2024-36012, CVE-2024-41057, CVE-2024-41058, CVE-2024-49996, CVE-2024-50115, CVE-2024-50124, CVE-2024-50125, CVE-2024-50262, CVE-2024-50264, CVE-2024-53057, CVE-2024-53103, CVE-2024-53141, CVE-2024-53142, CVE-2024-53150, CVE-2024-53156, CVE-2024-53173, CVE-2024-53179, CVE-2024-56600, CVE-2024-56601, CVE-2024-56602, CVE-2024-56603, CVE-2024-56604, CVE-2024-56605, CVE-2024-56608, CVE-2024-56614, CVE-2024-56631, CVE-2024-56642, CVE-2024-56662, CVE-2024-56664, CVE-2024-56672, CVE-2024-56708
CLSA: 2025:1738671431