Azure Linux 3.0 安全更新内核 (CVE-2025-37865)
medium Nessus 插件 ID 295392
语言：
简介
远程 Azure Linux 主机缺少一个或多个安全更新。描述
远程 Azure Linux 3.0 主机上安装的内核版本低于 测试的版本。因此，该程序受到 CVE-2025-37865 公告中提及的一个漏洞影响。- 已修复 Linux 内核中的下列漏洞：net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported Russell King reports that on the ZII dev rev B, deleting a bridge VLAN from a user port fails with -ENOENT:
https://lore.kernel.org/netdev/[email protected]/ This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(), which tries to find an MST entry in &chip->msts associated with the SID, but fails and returns -ENOENT as such. But we know that this chip does not support MST at all, so that is not surprising. The question is why does the guard in mv88e6xxx_mst_put() not exit early: if (!sid) return 0; And the answer seems to be simple: the sid comes from vlan.sid which supposedly was previously populated by mv88e6xxx_vtu_get(). But some chip->info->ops->vtu_getnext() implementations do not populate vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case, later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is just residual stack memory. Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge VLAN mapped to the default MSTI. For some chips, SID 0 is valid and installed by mv88e6xxx_stu_setup(). A chip which does not support the STU would implicitly only support mapping all VLANs to the default MSTI, so although SID 0 is not valid, it would be sufficient, if we were to zero-initialize the vlan structure, to fix the bug, due to the coincidence that a test for vlan.sid == 0 already exists and leads to the same (correct) behavior. Another option which would be sufficient would be to add a test for mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one which already exists in mv88e6xxx_mst_get(). But that placement means the caller will have to dereference vlan.sid, which means it will access uninitialized memory, which is not nice even if it ignores it later. So we end up making both modifications, in order to not rely just on the sid == 0 coincidence, but also to avoid having uninitialized structure fields which might get temporarily accessed.
(CVE-2025-37865)
请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
更新受影响的程序包。另见
插件详情
严重性: Medium
ID: 295392
文件名: azure_linux_CVE-2025-37865.nasl
版本: 1.1
类型: local
发布时间: 2026/1/22
最近更新时间: 2026/1/22
支持的传感器: Nessus
风险信息
VPR
风险因素: Medium
分数: 4.4
CVSS v2
风险因素: Medium
基本分数: 4.6
时间分数: 3.4
矢量: CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C
CVSS 分数来源: CVE-2025-37865
CVSS v3
风险因素: Medium
基本分数: 5.5
时间分数: 4.8
矢量: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
时间矢量: CVSS:3.0/E:U/RL:O/RC:C
漏洞信息
CPE: p-cpe:/a:microsoft:azure_linux:kernel-drivers-intree-amdgpu, p-cpe:/a:microsoft:azure_linux:kernel-drivers-accessibility, p-cpe:/a:microsoft:azure_linux:kernel-tools, p-cpe:/a:microsoft:azure_linux:kernel-debuginfo, p-cpe:/a:microsoft:azure_linux:kernel-devel, p-cpe:/a:microsoft:azure_linux:kernel-drivers-gpu, p-cpe:/a:microsoft:azure_linux:python3-perf, p-cpe:/a:microsoft:azure_linux:kernel-docs, x-cpe:/o:microsoft:azure_linux, p-cpe:/a:microsoft:azure_linux:kernel, p-cpe:/a:microsoft:azure_linux:kernel-drivers-sound, p-cpe:/a:microsoft:azure_linux:bpftool
必需的 KB 项: Host/local_checks_enabled, Host/AzureLinux/release, Host/AzureLinux/rpm-list, Host/cpu
易利用性: No known exploits are available
补丁发布日期: 2025/7/8
漏洞发布日期: 2025/5/5
参考资料信息
CVE: CVE-2025-37865