AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-abi-stablelists / kernel-core / 等多种漏洞 （ALMALINUX9.2：CLSA-2025：1758796886）
high Nessus 插件 ID 361135
语言：
简介
AlmaLinux 主机缺少一个或多个安全更新。描述
AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2025：2025：1758796886公告中提及的多个漏洞的影响。- 已修复 Linux 内核中的下列漏洞：can: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv It will trigger UAF for rx_kref of j1939_priv as following. cpu0 cpu1 j1939_sk_bind(socket0, ndev0, ...) j1939_netdev_start j1939_sk_bind(socket1, ndev0, ...) j1939_netdev_start j1939_priv_set j1939_priv_get_by_ndev_locked j1939_jsk_add ..... j1939_netdev_stop kref_put_lock(&priv->rx_kref, ...) kref_get(&priv->rx_kref, ...) REFCOUNT_WARN(addition on 0;...) ==================================================== refcount_t: addition on 0; use-after-free. WARNING:
CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0 RIP:
0010:refcount_warn_saturate+0x169/0x1e0 Call Trace: j1939_netdev_start+0x68b/0x920 j1939_sk_bind+0x426/0xeb0 ? security_socket_bind+0x83/0xb0 The rx_kref's kref_get() and kref_put() should use j1939_netdev_lock to protect. (CVE-2021-47459)
- 已修复 Linux 内核中的下列漏洞：net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg Currently, the hns3_remove function firstly uninstall client instance, and then uninstall acceletion engine device. The netdevice is freed in client instance uninstall process, but acceletion engine device uninstall process still use it to trace runtime information. This causes a use after free problem. So fixes it by check the instance register state to avoid use after free.
(CVE-2021-47596)
- 已修复 Linux 内核中的下列漏洞：i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() memcpy() is called in a loop while 'operation->length' upper bound is not checked and 'data_idx' also increments. (CVE-2022-48632)
- 已修复 Linux 内核中的下列漏洞：PM: hibernate: defer device probing when resuming from hibernation syzbot is reporting hung task at misc_open() [1], for there is a race window of AB-BA deadlock which involves probe_count variable. Currently wait_for_device_probe() from snapshot_open() from misc_open() can sleep forever with misc_mtx held if probe_count cannot become 0. When a device is probed by hub_event() work function, probe_count is incremented before the probe function starts, and probe_count is decremented after the probe function completed. There are three cases that can prevent probe_count from dropping to 0. (a) A device being probed stopped responding (i.e.
broken/malicious hardware). (b) A process emulating a USB device using /dev/raw-gadget interface stopped responding for some reason. (c) New device probe requests keeps coming in before existing device probe requests complete. The phenomenon syzbot is reporting is (b). A process which is holding system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside wait_for_device_probe(), but the probe function which is called from hub_event() work function is waiting for the processes which are blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface.
This patch mitigates (b) by deferring wait_for_device_probe() from snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g.
mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c), we should change the code to wait for only one device which contains the image for resuming from hibernation. I don't know how to address (a), for use of timeout for wait_for_device_probe() might result in loss of user data in the image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot interface. (CVE-2022-50202)
- 已修复 Linux 内核中的下列漏洞：net: sched: sfb: fix null pointer access issue when sfb_init() fails When the default qdisc is sfb, if the qdisc of dev_queue fails to be inited during mqprio_init(), sfb_reset() is invoked to clear resources. In this case, the q->qdisc is NULL, and it will cause gpf issue. The process is as follows: qdisc_create_dflt() sfb_init() tcf_block_get() --->failed, q->qdisc is NULL ... qdisc_put() ... sfb_reset() qdisc_reset(q->qdisc)
--->q->qdisc is NULL ops = qdisc->ops The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:qdisc_reset+0x2b/0x6f0 Call Trace: <TASK> sfb_reset+0x37/0xd0 qdisc_reset+0xed/0x6f0 qdisc_destroy+0x82/0x4c0 qdisc_put+0x9e/0xb0 qdisc_create_dflt+0x2c3/0x4a0 mqprio_init+0xa71/0x1760 qdisc_create+0x3eb/0x1000 tc_modify_qdisc+0x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100
____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK> (CVE-2022-50356)
请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
根据 TuxCare 公告 ALMALINUX9.2：CLSA-2025：1758796886 中的指南更新受影响的程序包。另见
插件详情
严重性: High
ID: 361135
文件名: tuxcare_alma_linux_9.2_CLSA-2025-1758796886.nasl
版本: 1.1
类型: Local
发布时间: 2026/10/1
最近更新时间: 2026/10/1
支持的传感器: Continuous Assessment, Nessus Agent, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus
风险信息
VPR
风险因素: Medium
分数: 4.9
百分位: 57.12
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-2025-38550
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/AlmaLinux/release, Host/AlmaLinux/rpm-list, Host/cpu
易利用性: No known exploits are available
补丁发布日期: 2025/9/25
漏洞发布日期: 2021/7/21
参考资料信息
CVE: CVE-2021-47459, CVE-2021-47596, CVE-2022-48632, CVE-2022-50202, CVE-2022-50356, CVE-2023-52445, CVE-2023-52530, CVE-2023-52777, CVE-2023-52999, CVE-2023-5345, CVE-2024-25743, CVE-2024-26739, CVE-2024-26939, CVE-2024-26974, CVE-2024-26982, CVE-2024-36921, CVE-2024-38635, CVE-2024-39487, CVE-2024-40958, CVE-2024-53203, CVE-2025-38332, CVE-2025-38550
CLSA: 2025:1758796886