AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / etc 多個弱點 （ALMALINUX9.2：CLSA-2025：1738671431）
high Nessus Plugin 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 中的指引更新受影響的套件。另請參閱
Plugin 詳細資訊
嚴重性: 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