AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞 （ALMALINUX9.2：CLSA-2026：1783362244）
high Nessus 插件 ID 360687
语言：
简介
AlmaLinux 主机缺少一个或多个安全更新。描述
AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2026：1783362244公告中提及的多个漏洞的影响。- 已修复 Linux 内核中的下列漏洞：extcon: Modify extcon device to be created after driver data is set Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace.
Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return) (CVE-2022-49308)
- 已修复 Linux 内核中的下列漏洞：tick/nohz: unexport __init-annotated tick_nohz_full_setup() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade.
Commit 28438794aba4 (modpost: fix section mismatch check for exported init/exit sections) fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost:
vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable
__ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c. (CVE-2022-49675)
- 已修复 Linux 内核中的下列漏洞：ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. (CVE-2022-49731)
- 已修复 Linux 内核中的下列漏洞：bridge: switchdev: Fix memory leaks when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm ip, pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:
[<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49812)
- 已修复 Linux 内核中的下列漏洞：capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |--
*xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks] (CVE-2022-49890)
请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
根据 TuxCare 公告 ALMALINUX9.2：CLSA-2026：1783362244 21 中的指南更新受影响的程序包。另见
插件详情
严重性: High
ID: 360687
文件名: tuxcare_alma_linux_9.2_CLSA-2026-1783362244.nasl
版本: 1.1
类型: Local
发布时间: 2026/10/1
最近更新时间: 2026/10/1
支持的传感器: Continuous Assessment, Nessus Agent, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
风险信息
VPR
风险因素: High
分数: 7
百分位: 98.33
Vendor
Vendor Severity: Important
CVSS v2
风险因素: Medium
基本分数: 6.5
时间分数: 4.8
矢量: CVSS2#AV:L/AC:L/Au:M/C:C/I:C/A:C
CVSS 分数来源: CVE-2026-31788
CVSS v3
风险因素: High
基本分数: 8.2
时间分数: 7.1
矢量: CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/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/AlmaLinux/release, Host/AlmaLinux/rpm-list, Host/cpu
易利用性: No known exploits are available
补丁发布日期: 2026/7/6
漏洞发布日期: 2021/7/21
参考资料信息
CVE: CVE-2021-47606, CVE-2022-49028, CVE-2022-49308, CVE-2022-49675, CVE-2022-49731, CVE-2022-49812, CVE-2022-49890, CVE-2022-50008, CVE-2022-50042, CVE-2022-50251, CVE-2022-50472, CVE-2022-50473, CVE-2022-50511, CVE-2022-50675, CVE-2022-50704, CVE-2023-52463, CVE-2023-52478, CVE-2023-52739, CVE-2023-52778, CVE-2023-52887, CVE-2023-53001, CVE-2023-53070, CVE-2023-53087, CVE-2023-53089, CVE-2023-53114, CVE-2023-53121, CVE-2023-53134, CVE-2023-53186, CVE-2023-53421, CVE-2023-53441, CVE-2023-53531, CVE-2023-53625, CVE-2023-53704, CVE-2023-53753, CVE-2023-53989, CVE-2023-54004, CVE-2023-54238, CVE-2023-54265, CVE-2023-54269, CVE-2023-54302, CVE-2023-54324, CVE-2024-26633, CVE-2024-26680, CVE-2024-26920, CVE-2024-26922, CVE-2024-26976, CVE-2024-35989, CVE-2024-36933, CVE-2024-38594, CVE-2024-41056, CVE-2024-42289, CVE-2024-43880, CVE-2024-46679, CVE-2024-47692, CVE-2024-47713, CVE-2024-49870, CVE-2024-49878, CVE-2024-49905, CVE-2024-49927, CVE-2024-49959, CVE-2024-49973, CVE-2024-50108, CVE-2024-50182, CVE-2024-53135, CVE-2024-53136, CVE-2024-53140, CVE-2024-53190, CVE-2024-53215, CVE-2024-56568, CVE-2024-56623, CVE-2024-56647, CVE-2024-57977, CVE-2024-58053, CVE-2024-58071, CVE-2025-21690, CVE-2025-21708, CVE-2025-21885, CVE-2025-22062, CVE-2025-37801, CVE-2025-37805, CVE-2025-37859, CVE-2025-37911, CVE-2025-38127, CVE-2025-38215, CVE-2025-38441, CVE-2025-38539, CVE-2025-38681, CVE-2025-39829, CVE-2025-39850, CVE-2025-40134, CVE-2025-40308, CVE-2025-71077, CVE-2025-71273, CVE-2026-23126, CVE-2026-23212, CVE-2026-23290, CVE-2026-23300, CVE-2026-23312, CVE-2026-23365, CVE-2026-23399, CVE-2026-23442, CVE-2026-23452, CVE-2026-31400, CVE-2026-31424, CVE-2026-31681, CVE-2026-31684, CVE-2026-31709, CVE-2026-31738, CVE-2026-31788, CVE-2026-43066, CVE-2026-43088, CVE-2026-43156, CVE-2026-43262, CVE-2026-43279, CVE-2026-43429, CVE-2026-43436, CVE-2026-43445, CVE-2026-43448, CVE-2026-43484, CVE-2026-45835, CVE-2026-46113
CLSA: 2026:1783362244