远程 Ubuntu 22.04 LTS 主机上安装的一个程序包受到 USN-7653-1 公告中提及的多个漏洞影响。

    据发现，Linux 内核的 CIFS 网络文件系统实现在处理上行调用时，未正确验证目标命名空间。攻击者可利用此问题泄露敏感信息。(CVE-2025-2312)

    在 Linux 内核中发现多个安全问题。攻击者可能利用这些问题入侵系统。此更新修正了以下子系统中的缺陷：

    - PowerPC 架构；

    - S390 架构；

    - 区块层子系统；

    - 串行 ATA 和并行 ATA 驱动程序；

    - 驱动程序核心；

    - 网络块设备驱动程序；

    - 字符设备驱动程序；

    - TPM 设备驱动程序；

    - 时钟框架和驱动程序；

    - FireWire 子系统；

    - GPIO 子系统；

    - GPU 驱动程序；

    - HID 子系统；

    - I3C 子系统；

    - InfiniBand 驱动程序；

    - IOMMU 子系统；

    - IRQ 芯片驱动程序；

    - 媒体驱动程序；

    - NVIDIA Tegra 内存控制器驱动程序；

    - Fastrpc 驱动程序；

    - 网络驱动程序；

    - Mellanox 网络驱动程序；

    - 操作性能点 (OPP) 驱动程序；

    - PCI 子系统；

    - x86 平台驱动程序；

    - i.MX PM 域；

    - PPS（每秒脉冲）驱动程序；

    - PTP 时钟框架；

    - 远程处理器子系统；

    - Real Time Clock 驱动程序；

    - SCSI 子系统；

    - QCOM SoC 驱动程序；

    - 媒体分段驱动程序；

    - TTY 驱动程序；

    - UFS 子系统；

    - USB Gadget 驱动程序；

    - USB 主机控制器驱动程序；

    - USB 串口驱动程序；

    - AFS 文件系统；

    - 文件系统基础设施；

    - BTRFS 文件系统；

    - F2FS 文件系统；

    - GFS2 文件系统；

    - NILFS2 文件系统；

    - 文件系统通知基础设施；

    - Overlay 文件系统；

    - Proc 文件系统；

    - SMB 网络文件系统；

    - UBI 文件系统；

    - Timer 子系统；

    - KVM 子系统；

    - Networking 核心；

    - ptr_ring 数据结构定义；

    - 网络子系统；

    - Amateur Radio 驱动程序；

    - XFRM 子系统；

    - 跟踪基础设施；

    - BPF 子系统；

    - 内核 CPU 基础架构；

    - Padata 并行执行机制；

    - printk 记录机制；

    - 内存管理；

    - 蓝牙子系统；

    - DCCP（数据报拥塞控制协议）；

    - IPv4 联网；

    - IPv6 联网；

    - MAC80211 子系统；

    - IEEE 802.15.4 子系统；

    - 多路径 TCP；

    - Netfilter；

    - NFC 子系统；

    - Open vSwitch；

    - Rose 网络层；

    - RxRPC 会话套接字；

    - 网络流量控制；

    - VMware vSockets 驱动程序；

    - Landlock 安全性；

    - Linux 安全模块 (LSM) 框架；

    - Tomoyo 安全模块；

    - SoC 音频核心驱动程序；(CVE-2025-21830, CVE-2025-21678, CVE-2025-21815, CVE-2024-57974, CVE-2025-21725, CVE-2025-21718, CVE-2025-21748, CVE-2025-21732, CVE-2024-57953, CVE-2025-21727, CVE-2025-21816, CVE-2025-21719, CVE-2024-53124, CVE-2024-58019, CVE-2025-38001, CVE-2025-21720, CVE-2025-21734, CVE-2025-21672, CVE-2025-21692, CVE-2024-58076, CVE-2025-21694, CVE-2024-58061, CVE-2025-21714, CVE-2025-21689, CVE-2024-49887, CVE-2024-57949, CVE-2025-38177, CVE-2025-21683, CVE-2025-21669, CVE-2025-21722, CVE-2024-57980, CVE-2025-38000, CVE-2025-37932, CVE-2024-58034, CVE-2024-58081, CVE-2025-21733, CVE-2025-21682, CVE-2024-57924, CVE-2025-21743, CVE-2024-57975, CVE-2025-37798, CVE-2024-58058, CVE-2025-21809, CVE-2025-21676, CVE-2024-57993, CVE-2025-21699, CVE-2024-58016, CVE-2025-21832, CVE-2025-21804, CVE-2024-58011, CVE-2024-58007, CVE-2025-21826, CVE-2024-58055, CVE-2025-21668, CVE-2025-21715, CVE-2024-58078, CVE-2025-21829, CVE-2025-21811, CVE-2025-21814, CVE-2024-58053, CVE-2025-21726, CVE-2025-21943, CVE-2025-37750, CVE-2025-21673, CVE-2024-57984, CVE-2025-37997, CVE-2025-21684, CVE-2025-21750, CVE-2024-58013, CVE-2025-21799, CVE-2024-58083, CVE-2025-21798, CVE-2025-21731, CVE-2025-21708, CVE-2024-57986, CVE-2025-21744, CVE-2024-58014, CVE-2025-21721, CVE-2024-58063, CVE-2024-57979, CVE-2024-58005, CVE-2025-21728, CVE-2025-21681, CVE-2025-21806, CVE-2024-57982, CVE-2024-58002, CVE-2024-58082, CVE-2025-21812, CVE-2025-21745, CVE-2024-58017, CVE-2025-21665, CVE-2025-21828, CVE-2025-37890, CVE-2024-57952, CVE-2024-57997, CVE-2025-21825, CVE-2025-21716, CVE-2024-57948, CVE-2025-21710, CVE-2025-21674, CVE-2025-21675, CVE-2024-50157, CVE-2025-21738, CVE-2025-22088, CVE-2024-58071, CVE-2024-58085, CVE-2025-21723, CVE-2025-21690, CVE-2025-21670, CVE-2025-21741, CVE-2024-57999, CVE-2025-21691, CVE-2024-58068, CVE-2024-58057, CVE-2024-57994, CVE-2024-58072, CVE-2025-21742, CVE-2024-58006, CVE-2024-58077, CVE-2024-58003, CVE-2025-21753, CVE-2024-57981, CVE-2024-57973, CVE-2024-58001, CVE-2025-21666, CVE-2025-21810, CVE-2025-21808, CVE-2024-57996, CVE-2024-58054, CVE-2024-57998, CVE-2025-21707, CVE-2025-21736, CVE-2025-21820, CVE-2025-21739, CVE-2024-57951, CVE-2025-21667, CVE-2024-58070, CVE-2025-21801, CVE-2024-58051, CVE-2024-58079, CVE-2025-21754, CVE-2024-58069, CVE-2025-37974, CVE-2025-21802, CVE-2025-21749, CVE-2024-57990, CVE-2024-58080, CVE-2025-21705, CVE-2025-21697, CVE-2024-58052, CVE-2025-21711, CVE-2024-58056, CVE-2025-21724, CVE-2024-58018, CVE-2025-21735, CVE-2024-58010, CVE-2025-21680)

Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 22.04 LTS / 24.04 LTS 主机上安装的程序包受到 USN-7596-1 公告中提及的多个漏洞的影响。

    在 Linux 内核中发现多个安全问题。攻击者可能利用这些问题入侵系统。此更新修正了以下子系统中的缺陷：

    - GPIO 子系统；

    - GPU 驱动程序；

    - InfiniBand 驱动程序；

    - IRQ 芯片驱动程序；

    - 网络驱动程序；

    - Mellanox 网络驱动程序；

    - i.MX PM 域；

    - SCSI 子系统；

    - USB 串口驱动程序；

    - AFS 文件系统；

    - GFS2 文件系统；

    - 文件系统基础设施；

    - 文件系统通知基础设施；

    - Overlay 文件系统；

    - Proc 文件系统；

    - SMB 网络文件系统；

    - Timer 子系统；

    - 内核 CPU 基础架构；

    - 内存管理；

    - Networking 核心；

    - DCCP（数据报拥塞控制协议）；

    - IPv6 联网；

    - IEEE 802.15.4 子系统；

    - Open vSwitch；

    - 网络流量控制；

    - VMware vSockets 驱动程序；（CVE-2025-21675、CVE-2025-21697、CVE-2025-21668、CVE-2024-57951、CVE-2025-21680、CVE-2024-50157、CVE-2025-21699、CVE-2025-21669、CVE-2025-21678、CVE-2025-21665、CVE-2024-57924、CVE-2024-57949、CVE-2024-53124、CVE-2025-21684、CVE-2025-21676、CVE-2025-21672、CVE-2025-21682、CVE-2025-21670、CVE-2025-21690、CVE-2025-21673、CVE-2025-21691、CVE-2024-57952、CVE-2025-21674、CVE-2025-21689、CVE-2025-21943、CVE-2025-21692、CVE-2025-21667、CVE-2025-21666、CVE-2024-57948、CVE-2025-21694、CVE-2025-21683、CVE-2025-21681）

Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程的 Debian 11 主机安装了受多个漏洞影响的包，如 dla-4561 公告中提到的。

    ------------------------------------------------------------------------- Debian LTS 咨询 DLA-4561-1 debian-lts@lists.debian.org https://www.debian.org/lts/security/Ben Hutchings 2026年5月2日 https://wiki.debian.org/LTS-------------------------------------------------------------------------

    程序包：linux-6.1 版本：6.1.170-1~deb11u1 CVE ID：CVE-2023-53228 CVE-2023-53510 CVE-2023-53545 CVE-2024-47736 CVE-2024-47809 CVE-2024-49998 CVE-2024-50298 CVE-2024-56719 CVE-2025-21676 CVE-2025-21682 CVE-2025-37945 CVE-2025-37980 CVE-2025-38105 CVE-2025-38162 CVE-2025-38192 CVE-2025-38250 CVE-2025-38303 CVE-2025-38436 CVE-2025-38626 CVE-2025-38659 CVE-2025-38704 CVE-2025-39748 CVE-2025-39764 CVE-2025-39863 CVE-2025-40005 CVE-2025-40016 CVE-2025-40135 CVE-2025-40219 CVE-2025-40242 CVE-2025-40261 CVE-2025-40358 CVE-2025-68206 CVE-2025-68239 CVE-2025-68265 CVE-2025-71067 CVE-2025-71161 CVE-2025-71221 CVE-2025-71265 CVE-2025-71266 CVE-2025-71267 CVE-2025-71269 CVE-2026-23100 CVE-2026-23113 CVE-2026-23141 CVE-2026-23154 CVE-2026-23157 CVE-2026-23204 CVE-2026-23227 CVE-2026-23231 CVE-2026-23242 CVE-2026-23243 CVE-2026-23245 CVE-2026-23253 CVE-2026-23270 CVE-2026-23271 CVE-2026-23273 CVE-2026-23274 CVE-2026-23277 CVE-2026-23279 CVE-2026-23281 CVE-2026-23284 CVE-2026-23286 CVE-2026-23287 CVE-2026-23289 CVE-2026-23290 CVE-2026-23291 CVE-2026-23292 CVE-2026-23293 CVE-2026-23296 CVE-2026-23298 CVE-2026-23300 CVE-2026-23303 CVE-2026-23304 CVE-2026-23306 CVE-2026-23307 CVE-2026-23312 CVE-2026-23315 CVE-2026-23317 CVE-2026-23318 CVE-2026-23319 CVE-2026-23321 CVE-2026-23324 CVE-2026-23335 CVE-2026-23336 CVE-2026-23339 CVE-2026-23340 CVE-2026-23343 CVE-2026-23351 CVE-2026-23352 CVE-2026-23356 CVE-2026-23357 CVE-2026-23359 CVE-2026-23362 CVE-2026-23364 CVE-2026-23365 CVE-2026-23367 CVE-2026-23368 CVE-2026-23370 CVE-2026-23372 CVE-2026-23378 CVE-2026-23379 CVE-2026-23381 CVE-2026-23382 CVE-2026-23388 CVE-2026-23391 CVE-2026-23392 CVE-2026-23395 CVE-2026-23396 CVE-2026-23397 CVE-2026-23398 CVE-2026-23401 CVE-2026-23414 CVE-2026-23420 CVE-2026-23422 CVE-2026-23426 CVE-2026-23428 CVE-2026-23434 CVE-2026-23438 CVE-2026-23439 CVE-2026-23446 CVE-2026-23449 CVE-2026-23450 CVE-2026-23452 CVE-2026-23454 CVE-2026-23455 CVE-2026-23456 CVE-2026-23457 CVE-2026-23458 CVE-2026-23460 CVE-2026-23462 CVE-2026-23463 CVE-2026-23474 CVE-2026-23475 CVE-2026-31389 CVE-2026-31391 CVE-2026-31392 CVE-2026-31393 CVE-2026-31396 CVE-2026-31399 CVE-2026-31400 CVE-2026-31402 CVE-2026-31403 CVE-2026-31405 CVE-2026-31408 CVE-2026-31409 CVE-2026-31411 CVE-2026-31412 CVE-2026-31414 CVE-2026-31415 CVE-2026-31416 CVE-2026-31417 CVE-2026-31418 CVE-2026-31421 CVE-2026-31422 CVE-2026-31423 CVE-2026-31424 CVE-2026-31425 CVE-2026-31426 CVE-2026-31427 CVE-2026-31428 CVE-2026-31431 CVE-2026-31433 CVE-2026-31434 CVE-2026-31441 CVE-2026-31446 CVE-2026-31447 CVE-2026-31448 CVE-2026-31450 CVE-2026-31452 CVE-2026-31453 CVE-2026-31454 CVE-2026-31455 CVE-2026-31464 CVE-2026-31466 CVE-2026-31467 CVE-2026-31469 CVE-2026-31473 CVE-2026-31476 CVE-2026-31477 CVE-2026-31478 CVE-2026-31480 CVE-2026-31483 CVE-2026-31485 CVE-2026-31492 CVE-2026-31494 CVE-2026-31495 CVE-2026-31496 CVE-2026-31497 CVE-2026-31498 CVE-2026-31503 CVE-2026-31504 CVE-2026-31507 CVE-2026-31508 CVE-2026-31509 CVE-2026-31510 CVE-2026-31512 CVE-2026-31515 CVE-2026-31518 CVE-2026-31519 CVE-2026-31520 CVE-2026-31521 CVE-2026-31522 CVE-2026-31523 CVE-2026-31524 CVE-2026-31533 CVE-2026-31540 CVE-2026-31545 CVE-2026-31546 CVE-2026-31548 CVE-2026-31549 CVE-2026-31550 CVE-2026-31551 CVE-2026-31552 CVE-2026-31555 CVE-2026-31563 CVE-2026-31565 CVE-2026-31566 CVE-2026-31570 CVE-2026-31628 CVE-2026-31634 CVE-2026-31649 CVE-2026-31651 CVE-2026-31656 CVE-2026-31657 CVE-2026-31658 CVE-2026-31659 CVE-2026-31660 CVE-2026-31661 CVE-2026-31662 CVE-2026-31664 CVE-2026-31665 CVE-2026-31667 CVE-2026-31668 CVE-2026-31669 CVE-2026-31670 CVE-2026-31671 CVE-2026-31672 CVE-2026-31674 CVE-2026-31678 CVE-2026-31679 CVE-2026-31680 CVE-2026-31682 CVE-2026-31683 CVE-2026-31689 CVE-2026-31695 CVE-2026-31720 CVE-2026-31721 CVE-2026-31726 CVE-2026-31728 CVE-2026-31737 CVE-2026-31738 CVE-2026-31747 CVE-2026-31748 CVE-2026-31749 CVE-2026-31751 CVE-2026-31752 CVE-2026-31754 CVE-2026-31755 CVE-2026-31756 CVE-2026-31758 CVE-2026-31759 CVE-2026-31761 CVE-2026-31762 CVE-2026-31763 CVE-2026-31768 CVE-2026-31770 CVE-2026-31773 CVE-2026-31776 CVE-2026-31778 CVE-2026-31779 CVE-2026-31780 CVE-2026-31781 CVE-2026-31786 CVE-2026-31787 CVE-2026-31788 CVE-2026-43011 CVE-2026-43013 CVE-2026-43014 CVE-2026-43015 CVE-2026-43017 CVE-2026-43018 CVE-2026-43020 CVE-2026-43023 CVE-2026-43024 CVE-2026-43025 CVE-2026-43026 CVE-2026-43027 CVE-2026-43028 CVE-2026-43030 CVE-2026-43032 CVE-2026-43033 CVE-2026-43035 CVE-2026-43037 CVE-2026-43038 CVE-2026-43040 CVE-2026-43041 CVE-2026-43043 CVE-2026-43046 CVE-2026-43047 CVE-2026-43050 CVE-2026-43051 CVE-2026-43054 CVE-2026-43057

    在 Linux 内核中发现多个可能导致权限升级、拒绝服务或信息泄漏的漏洞。

    对于 Debian 11 Bullseye，这些问题在 6.1.170-1~deb11u1 版本中得到了修复。

    建议您升级 linux-6.1 程序包。

    如需了解 linux-6.1 的详细安全状态，请参阅其安全跟踪页面：
    https://security-tracker.debian.org/tracker/linux-6.1

    有关 Debian LTS 安全公告、如何将这些更新应用到系统以及常见问题解答的更多信息，请访问以下网址：https://wiki.debian.org/LTSAttachment:signature.ascDescription: PGP signature

Tenable 已直接从 Debian 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Ubuntu 24.04 LTS / 24.10 主机上安装的程序包受到 USN-7445-1 公告中提及的多个漏洞的影响。

    在 Linux 内核中发现多个安全问题。攻击者可能利用这些问题入侵系统。此更新修正了以下子系统中的缺陷：

    - GPIO 子系统；

    - GPU 驱动程序；

    - IRQ 芯片驱动程序；

    - 网络驱动程序；

    - Mellanox 网络驱动程序；

    - x86 平台驱动程序；

    - i.MX PM 域；

    - SCSI 子系统；

    - USB 串口驱动程序；

    - AFS 文件系统；

    - GFS2 文件系统；

    - 文件系统基础设施；

    - Proc 文件系统；

    - SMB 网络文件系统；

    - Timer 子系统；

    - 内核 CPU 基础架构；

    - 内存管理；

    - Networking 核心；

    - Ethtool 驱动程序；

    - IEEE 802.15.4 子系统；

    - Open vSwitch；

    - 网络流量控制；

    - VMware vSockets 驱动程序；（CVE-2025-21685、CVE-2025-21684、CVE-2025-21756、CVE-2025-21670、CVE-2024-57949、CVE-2025-21677、CVE-2025-21680、CVE-2025-21703、CVE-2024-57952、CVE-2025-21674、CVE-2025-21701、CVE-2025-21691、CVE-2025-21689、CVE-2025-21668、CVE-2025-21665、CVE-2025-21683、CVE-2025-21675、CVE-2025-21672、CVE-2024-57948、CVE-2025-21669、CVE-2025-21673、CVE-2025-21692、CVE-2025-21699、CVE-2025-21702、CVE-2025-21682、CVE-2025-21690、CVE-2025-21681、CVE-2025-21695、CVE-2025-21696、CVE-2025-21700、CVE-2025-21678、CVE-2025-21676、CVE-2024-57950、CVE-2025-21666、CVE-2025-21694、CVE-2025-21693、CVE-2025-21993、CVE-2024-57951、CVE-2025-21697、CVE-2025-21667）

Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

AlmaLinux 9.6 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.6：CLSA-2026：1779434490公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C
    --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. (CVE-2022-48931)

  - 已修复 Linux 内核中的下列漏洞：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

  - 已修复 Linux 内核中的下列漏洞：ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - 已修复 Linux 内核中的下列漏洞：tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - 已修复 Linux 内核中的下列漏洞：linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP:
    0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX:
    0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 (CVE-2022-49670)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

Rocky Linux 9.6 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.6：CLSA-2026：1779434490公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C
    --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. (CVE-2022-48931)

  - 已修复 Linux 内核中的下列漏洞：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

  - 已修复 Linux 内核中的下列漏洞：ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
    (CVE-2022-49627)

  - 已修复 Linux 内核中的下列漏洞：tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 (tracing:
    fix double free) said, the double free problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no double free problem before. Conversely, after that commit, we get a memory leak problem because the above N-th var_defs.name is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm bash, pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 (CVE-2022-49648)

  - 已修复 Linux 内核中的下列漏洞：linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP:
    0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX:
    0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 (CVE-2022-49670)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - ethbnxtXDP 清理后始终重新计算功能修复分离 XDP 时的 null-deref 重新计算功能。之前版本# ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp# ip li set dev eth0 xdp off# ethtool -k eth0 | grep gro rx-gro-hwoff [上的请求] 之后# ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp# ip li set dev eth0 xdp off# ethtool -k eth0 | grep gro rx-gro-hw grep gro rx-gro-hw: on HW-GRO 不会自动重新启用这一事实只是一个次要烦恼。真正的问题在于这些功能在另一次刚好调用 netdev_update_features() 的重新配置期间将随机返回。该驱动程序无法以非常健全的方式同时重新配置两个项目。
    从提交 98ba1d931f61 (bnxt_en修复 __bnxt_reserve_rings()) 开始我们只会在 Rx 环的有效数量变更时才会重新配置 RSS 哈希表。如果启用了 HW-GRO则有效响铃数量是用户看到的数量的 2 倍。因此如果我们处于错误状态下 XDP 关闭后待定 HW-GRO 重新启用并且我们将环降低 / 2 - 执行 2x 的 HW-GRO 环与执行 / 2 的 ethtool -L 可能会互相取消以及 if (old_rx_rings != bp->hw_resc.resv_rx_rings && 中的条件
    __bnxt_reserve_rings() 将为 false。The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50
    __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0 当我们尝试访问已释放的环时。此问题自添加 XDP 支持以来便确实存在但在提交 98ba1d931f61bnxt_en修复 __bnxt_reserve_rings() 中的 RSS 逻辑之前并未造成重大问题。 (CVE-2025-21682)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

远程 Oracle Linux 9 主机上安装的程序包受到 ELSA-2025-20480 公告中提及的多个漏洞影响。

    - sunrpc在 svc auth 处理期间将 SVC_GARBAGE 处理为认证错误 (Jeff Layton) [Orabug: 38178286] {CVE-2025-38089}
    - 添加 Zen34 客户端 (Borislav Petkov (AMD)) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - x86/process在 MONITOR 之前移动缓冲区清除 (Kim Phillips) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - 添加正常计数器 (Borislav Petkov (AMD)) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - KVMSVM向客户机公告 TSA CPUID 位 (Borislav Petkov (AMD)) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - x86/缺陷添加临时计划程序攻击缓解 (Borislav Petkov (AMD)) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - x86/缺陷将 MDS 机械重命名为更通用的名称 (Borislav Petkov (AMD)) [Orabug: 38023239] {CVE-2024-36350} {CVE-2024-36357}
    - block修复将 folio 添加到 bio (Ming Lei) [Orabug: 37844657] {CVE-2025-22122}
    - f2fs修复以避免访问未初始化的curseg (Chao Yu) [Orabug: 37844644] {CVE-2025-22123}
    - gpio: virtuser修复潜在的越界写入 (Markus Burri) [Orabug: 38095181] {CVE-2025-38082}
    - net_schedhfsc地址可重入队列两次向 eltree 添加类 (Pedro Tammela) [Orabug
    38049363] {CVE-2025-38001}
    - smb客户端修复 cifs_fill_dirent 中的释放后使用 (Zhaolong Wang) [Orabug: 38094970] {CVE-2025-38051}
    - platform/x86dell-wmi-sysman避免 current_password_store() 中的缓冲区溢出 (Vladimir Moskovkin) [Orabug: 38095141] {CVE-2025-38077}
    - ALSApcm修复 PCM OSS 层的缓冲区访问争用 (Takashi Iwai) [Orabug: 38095145] {CVE-2025-38078}
    - canbcm添加 procfs 内容缺少的 rcu 读取保护 (Oliver Hartkopp) [Orabug: 38049369] {CVE-2025-38003}
    - canbcm为 bcm_op 运行时更新添加锁定 (Oliver Hartkopp) [Orabug: 38049374] {CVE-2025-38004}
    - padata请勿泄漏 reorder_work 中的引用计数 (Dominik Grzegorzek) [Orabug38094842] {CVE-2025-38031}
    - cryptoalgif_hash - 修复 hash_accept 中的双重释放 (Ivan Pravdin) [Orabug: 38095153] {CVE-2025-38079}
    - net/tipc修复 tipc_aead_encrypt_done 中的 slab-use-after-free 读取 (Wang Liu) [Orabug: 38094978] {CVE-2025-38052}
    - sch_hfsc修复在 hfsc_enqueue() 中使用 peek 时的 qlen 核算缺陷 (Cong Wang) [Orabug: 38049357] {CVE-2025-38000}
    - idpf修复 idpf_features_check 中的 null-ptr-deref (Pavan Kumar Linga) [Orabug: 38094982] {CVE-2025-38053}
    - ptpocp限制汇总输出函数中的信号/频率计数 (Sagi Maimon) [Orabug: 38094984] {CVE-2025-38054}
    - perf/x86/intel修复包含 sample_freq 的 PEBS-via-PT 的段错误 (Adrian Hunter) [Orabug: 38094988] {CVE-2025-38055}
    - ASoCSOF: Intelhda重新加载模块时修复 UAF (Tabian Barnes) [Orabug: 38094991] {CVE-2025-38056}
    - espintcp修复 skb 泄露 (Sabrina Dubroca) [Orabug: 38094993] {CVE-2025-38057}
    - __legitimize_mnt()应在 mount_lock 下进行 MNT_SYNC_UMOUNT 检查 (Al Viro) [Orabug: 38095000] {CVE-2025-38058}
    - x86/Kconfig使 CFI_AUTO_DEFAULT 依赖于 !RUST 或 Rust >= 1.88 (Pawel Anikiel) [Orabug: 38094847] {CVE-2025-38033}
    - btrfs如果无有效 csum 树则避免空指针取消引用 (Qu Wenruo) [Orabug38095010] {CVE-2025-38059}
    - btrfs修正 btrfs__prelim_ref 中 prelim_ref 参数的顺序 (Goldwyn Rodrigues) [Orabug:
    38094856] {CVE-2025-38034}
    - nvmet-tcp不恢复空 sk_state_change (Alistair Francisco) [Orabug: 38094863] {CVE-2025-38035}
    - vxlan注释 FDB 数据争用 (Ido Schimmel) [Orabug: 38094879] {CVE-2025-38037}
    - cpufreqamd-pstate删除 set_boost 中不必要的 driver_lock (Dhananjay Ugwekar) [Orabug: 38094888] {CVE-2025-38038}
    - drm/amd/display增加 block_sequence 数组大小 (Joshua Aberback) [Orabug38095164] {CVE-2025-38080}
    - bpfcopy_verifier_state() 应复制“loop_entry”字段 (Eduard Zingerman) [Orabug38095018] {CVE-2025-38060}
    - serialmctrl_gpio将 disable_ms 拆分为 sync 和 no_sync API (Alexis Lothore) [Orabug: 38094901] {CVE-2025-38040}
    - netpktgen修复 pktgen_thread_write() 中用户指定缓冲区之外的访问 (Peter Seiderer) [Orabug
    38095024] {CVE-2025-38061}
    - genirq/msi将 IOMMU IOVA 直接存储在 msi_desc 而不是 iommu_cookie 中 (Jason Gunthorpe) [Orabug:
    38095031] {CVE-2025-38062}
    - dm修复 REQ_PREFLUSH 造成的无条件 IO 节流 (Jinliang Zheng) [Orabug38095038] {CVE-2025-38063}
    - firmwarearm_ffa设置 ffa 设备的 dma_mask (Viresh Kumar) [Orabug38094925] {CVE-2025-38043}
    - mediacx231xx设置 417 的 device_caps (Hans Verkuil) [Orabug38094934] {CVE-2025-38044}
    - Orangefs不截断文件大小 (Matthew Wilcox) [Orabug: 38095056] {CVE-2025-38065}
    - dm 缓存通过阻止设备恢复失败的重试来防止 BUG_ON (Ming-Hung Tsai) [Orabug:
    38095063] {CVE-2025-38066}
    - cryptolzo - 修复压缩缓冲区溢出 (Herbert Xu) [Orabug38095079] {CVE-2025-38068}
    - PCI 端点pci-epf-test修复导致内核 oops 的双重释放 (Christian Bruel) [Orabug
    38095087] {CVE-2025-38069}
    - wifiiwlwifi修复调试操作顺序 (Johannes Berg) [Orabug38094942] {CVE-2025-38045}
    - x86/mm检查 memblock_phys_alloc_range() 的返回值 (Philip Redkin) [Orabug: 38095101] {CVE-2025-38071}
    - libnvdimm/labels修复 nd_label_data_init() 中的除法错误 (Robert Richter) [Orabug: 38095109] {CVE-2025-38072}
    - spi-rockchip修复寄存器越界访问 (Luis de Arquer) [Orabug38095173] {CVE-2025-38081}
    - x86/fred修复启用 FRED 的 S4 恢复期间的系统挂起 (Xin Li) [Orabug: 38094951] {CVE-2025-38047}
    - block修复 set_blocksize 和读取路径之间的争用 (Darrick J. Wong) [Orabug38095117] {CVE-2025-38073}
    - virtio_ring通过将 event_triggered 标记为 KCSAN 的 racy修复数据争用 (Zhongqiu Han) [Orabug:
    38094958] {CVE-2025-38048}
    - scsitargetiscsi修复已删除连接的超时 (Dmitry Bogdanov) [Orabug38095134] {CVE-2025-38075}
    - usbtypecucsidisplayport修复死锁 (Andrei Kuchynski) [Orabug: 37977018] {CVE-2025-37967}
    - 蓝牙btnxpuart修复 FW 发布期间的内核错误 (Neeraj Sanjay Kale) [Orabug: 37844459] {CVE-2025-22102}
    - iiolight opt3001修复因并发标记访问导致的死锁 (Luca Ceresoli) [Orabug: 37977026] {CVE-2025-37968}
    - mm/page_alloc修复未接受内存处理中的争用条件 (Kirill A. Shutemov) [Orabug: 38094767] {CVE-2025-38008}
    - dmaengineidxd使用 idxd_cleanup() 帮助程序重构删除调用 (Shuai Xue) [Orabug38094790] {CVE-2025-38014}
    - dmaengineidxd修复 idxd_alloc 的错误处理路径中的内存泄漏 (Shuai Xue) [Orabug: 38094793] {CVE-2025-38015}
    - dmaenginetik3-udma添加缺失的锁定 (Ronald Wahl) [Orabug38094756] {CVE-2025-38005}
    - wifimt76在删除驱动程序时禁用 napi (Fedor Pchelkin) [Orabug38094770] {CVE-2025-38009}
    - phytegraxusb将位掩码用于 UTMI pad 电源状态跟踪 (Wane Chang) [Orabug: 38094777] {CVE-2025-38010}
    - drm/amdgpucsa unmap 使用不间断锁定 (Philip Yang) [Orabug: 38094779] {CVE-2025-38011}
    - HIDbpf中止调度如果设备遭到破坏 (Rongrong) [Orabug38094796] {CVE-2025-38016}
    - sched_extbpf_iter_scx_dsq_new() 应始终初始化迭代器 (Tejun Heo) [Orabug: 38094786] {CVE-2025-38012}
    - net/tls修复 alloc_page 失败时的内核错误 (Pengtao He) [Orabug: 38094802] {CVE-2025-38018}
    - mlxswspectrum_router修复删除 GRE 网络设备时的释放后使用 (Ido Schimmel) [Orabug
    38094804] {CVE-2025-38019}
    - wifimac80211分配 struct cfg80211_scan_request 后设置 n_channels (Kees Cook) [Orabug
    38094788] {CVE-2025-38013}
    - regulatormax20086修复无效的内存访问 (Cosmin Tanislav) [Orabug: 38094833] {CVE-2025-38027}
    - net/mlx5e禁用上行链路representor配置文件的 MACsec 卸载 (Carolina Jubran) [Orabug: 38094808] {CVE-2025-38020}
    - net_sched ->change() 期间也刷新 gso_skb 列表 (Cong Wang) [Orabug37998128] {CVE-2025-37992}
    - RDMA/core修复“KASAN: slab-use-after-free Read in ib_register_device”问题 (Zhu Yanjun) [Orabug:
    38094813] {CVE-2025-38022}
    - nfs处理解锁路径中的 nfs_get_lock_context 失败 (Li Lingfeng) [Orabug38094818] {CVE-2025-38023}
    - HIDuclogic在 uclogic_input_configured() 中添加空检查 (Henry Martin) [Orabug: 38094764] {CVE-2025-38007}
    - RDMA/rxe修复 rxe_queue_cleanup 缺陷中的 slab-use-after-free 读取 (Zhu Yanjun) [Orabug: 38094827] {CVE-2025-38024}
    - arm64bpf仅缓解非特权用户加载的 cBPF 程序 (James Morse) [Orabug: 37977004] {CVE-2025-37963}
    - arm64bpf将 BHB 缓解添加到 cBPF 程序的尾声 (James Morse) [Orabug37976926] {CVE-2025-37948}
    - usbtypecucsidisplayport修复空指针访问 (Andrei Kuchynski) [Orabug: 38015126] {CVE-2025-37994}
    - 模块确保 kobject_put() 对于模块类型 kobjects 是安全的 (Dmitry Antipov) [Orabug: 38015131] {CVE-2025-37995}
    - memblock接受分配的内存然后在 memblock_double_array() 中使用 (Tom Lendacky) [Orabug:
    37976994] {CVE-2025-37960}
    - xenbus使用 kref 跟踪 req 生命周期 (Jason Andryuk) [Orabug: 37976934] {CVE-2025-37949}
    - smb 客户端通过租用中断避免 open_cached_dir 中发生争用 (Paul Aurich) [Orabug37976959] {CVE-2025-37954}
    - drm/amd/display修复 dml 帮助程序中的无效上下文错误 (Roman Li) [Orabug: 37977185] {CVE-2025-37965}
    - drm/v3d如果跳过重置则将作业添加至待定列表 (Maira Canal) [Orabug: 37976942] {CVE-2025-37951}
    - iioimu st_lsm6dsx修复 st_lsm6dsx_read_taged_fifo 中可能的锁定 (Silvano Seva) [Orabug:
    37977031] {CVE-2025-37969}
    - iioimust_lsm6dsx修复 st_lsm6dsx_read_fifo 中可能的锁定 (Silvano Seva) [Orabug: 37977037] {CVE-2025-37970}
    - KVMSVMSHUTDOWN 拦截时强制离开 SMM 模式 (Mikhail Lobanov) [Orabug37976977] {CVE-2025-37957}
    - mm/huge_memory修复取消引用无效的 pmd 迁移条目 (Gavin Guo) [Orabug37976982] {CVE-2025-37958}
    - x86/mm消除可能会无意间跳过 TLB 刷新的窗口 (Dave Hansen) [Orabug: 37977013] {CVE-2025-37964}
    - stagingbcm2835-camera初始化 v4l2_dev 中的 dev (Dave Stevenson) [Orabug: 37977042] {CVE-2025-37971}
    - Inputmtk-pmic-keys - 修复可能存在的空指针取消引用 (Gary Bisson) [Orabug37977044] {CVE-2025-37972}
    - bpfbpf_redirect_peer 上的清理数据包(Paul Chaignon) [Orabug37976990] {CVE-2025-37959}
    - netfilteripset修复哈希类型中的区域锁定 (Jozsef Kadlecsik) [Orabug38015141] {CVE-2025-37997}
    - ipvs修复 do_output_route4 中 saddr 的 uninit-value (Julian Anastasov) [Orabug: 37976996] {CVE-2025-37961}
    - canm_canm_can_class_allocate_dev()初始化设备探测上的旋转锁定 (Antonios Salios) [Orabug
    38015123] {CVE-2025-37993}
    - virtio-net在 virtnet_xsk_pool_enable() 中发生错误时释放 xsk_buffs (Jakub Kicinski) [Orabug: 37976969] {CVE-2025-37955}
    - sch_htb使 htb_deactivate() 幂等 (Cong Wang) [Orabug: 37977176] {CVE-2025-37953}
    - ksmbd修复 parse_lease_state() 中的内存泄漏 (Zhaolong Wang) [Orabug: 37977180] {CVE-2025-37962}
    - openvswitch修复 output_userspace() 中不安全的属性解析 (Eelco Chaudron) [Orabug38015148] {CVE-2025-37998}
    - ksmbd修复 __close_file_table_ids 中的 UAF (Sean Heelan) [Orabug: 37976951] {CVE-2025-37952}
    - ksmbd通过验证 *pos 防止越界流写入 (Norbert Szetei) [Orabug: 37976923] {CVE-2025-37947}
    - ksmbd防止使用空字符串重命名 (Namjae Jeon) [Orabug37976972] {CVE-2025-37956}
    - s390/pci当 PF 具有子 VF 时修复 disable_slot() 中的重复 pci_dev_put() (Niklas Schnelle) [Orabug
    37976920] {CVE-2025-37946}
    - wificfg80211修复多链接元素碎片整理期间的越界访问 (Veerendranath Jakkam) [Orabug: 37977046] {CVE-2025-37973}
    - s390/pci修复缺少检查的 zpci_create_device() 错误返回 (Niklas Schnelle) [Orabug: 37977050] {CVE-2025-37974}
    - fs/erofs/fileio调用 bio_add_folio() 之后调用 erofs_onlinefolio_split() (Max Kellermann) [Orabug
    38015155] {CVE-2025-37999}
    - mlxbf-bootctl在 secure_boot_fuse_state_show() 中使用 sysfs_emit_at() (David Thomson) [Orabug
    37964051,38037120] {CVE-2025-37866}

Tenable 已直接从 Oracle Linux 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 22.04 LTS / 24.04 LTS 主机上安装的程序包受到 USN-7595-1 公告中提及的多个漏洞的影响。

    据发现，Linux 内核的 CIFS 网络文件系统实现在处理上行调用时，未正确验证目标命名空间。攻击者可利用此问题泄露敏感信息。(CVE-2025-2312)

    在 Linux 内核中发现多个安全问题。攻击者可能利用这些问题入侵系统。此更新修正了以下子系统中的缺陷：

    - GPIO 子系统；

    - GPU 驱动程序；

    - InfiniBand 驱动程序；

    - IRQ 芯片驱动程序；

    - 网络驱动程序；

    - Mellanox 网络驱动程序；

    - i.MX PM 域；

    - SCSI 子系统；

    - USB 串口驱动程序；

    - AFS 文件系统；

    - GFS2 文件系统；

    - 文件系统基础设施；

    - 文件系统通知基础设施；

    - Overlay 文件系统；

    - Proc 文件系统；

    - SMB 网络文件系统；

    - Timer 子系统；

    - 内核 CPU 基础架构；

    - 内存管理；

    - Networking 核心；

    - DCCP（数据报拥塞控制协议）；

    - IPv6 联网；

    - IEEE 802.15.4 子系统；

    - Open vSwitch；

    - 网络流量控制；

    - VMware vSockets 驱动程序；（CVE-2025-21943、CVE-2025-21672、CVE-2024-57952、CVE-2024-57949、CVE-2025-21683、CVE-2025-21690、CVE-2025-21699、CVE-2025-21676、CVE-2024-57924、CVE-2025-21694、CVE-2024-57948、CVE-2025-21675、CVE-2024-57951、CVE-2025-21692、CVE-2025-21684、CVE-2025-21668、CVE-2025-21665、CVE-2025-21667、CVE-2025-21670、CVE-2025-21674、CVE-2025-21697、CVE-2024-53124、CVE-2025-21666、CVE-2025-21682、CVE-2025-21680、CVE-2025-21681、CVE-2025-21691、CVE-2025-21669、CVE-2025-21673、CVE-2024-50157、CVE-2025-21689、CVE-2025-21678）

Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Ubuntu 24.04 LTS / 24.10 主机上安装的程序包受到 USN-7448-1 公告中提及的多个漏洞的影响。

    据发现，Linux 内核的 CIFS 网络文件系统实现在处理上行调用时，未正确验证目标命名空间。攻击者可利用此问题泄露敏感信息。(CVE-2025-2312)

    在 Linux 内核中发现多个安全问题。攻击者可能利用这些问题入侵系统。此更新修正了以下子系统中的缺陷：

    - GPIO 子系统；

    - GPU 驱动程序；

    - IRQ 芯片驱动程序；

    - 网络驱动程序；

    - Mellanox 网络驱动程序；

    - x86 平台驱动程序；

    - i.MX PM 域；

    - SCSI 子系统；

    - USB 串口驱动程序；

    - AFS 文件系统；

    - GFS2 文件系统；

    - 文件系统基础设施；

    - Proc 文件系统；

    - SMB 网络文件系统；

    - Timer 子系统；

    - 内核 CPU 基础架构；

    - 内存管理；

    - Networking 核心；

    - Ethtool 驱动程序；

    - IEEE 802.15.4 子系统；

    - Open vSwitch；

    - 网络流量控制；

    - VMware vSockets 驱动程序CVE-2025-21694、 CVE-2025-21993、 CVE-2025-21684、 CVE-2025-21681、 CVE-2025-21675、 CVE-2025-21672、 CVE-2025-21696、 CVE-2025-21691、 CVE-2025-21683、 CVE-2025-21666、 CVE-2025-21682、 CVE-2025-21697、 CVE-2025-21668、 CVE-2025-21701、 CVE-2025-21670、 CVE-2025-21676、 CVE-2025-21695、 CVE-2025-21692、 CVE-2025-21674、 CVE-2024-57948CVE-2025-21699、 CVE-2025-21677[] 、 、 CVE-2024-57951、 CVE-2025-21702、 CVE-2025-21700、 CVE-2024-57949、 CVE-2025-21669、 CVE-2025-21703、 CVE-2025-21756、 CVE-2025-21667、 CVE-2024-57952、 CVE-2024-57950、 CVE-2025-21685、 CVE-2025-21693、 CVE-2025-21678、 CVE-2025-21665、 CVE-2025-21680、 CVE-2025-21689、 CVE-2025-21690、 CVE-2025-21673)

Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2026：1783791447公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：phy: mdio: fix memory leak Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. (CVE-2021-47416)

  - 在 Linux 内核的 TeleTYpe 子系统中发现越界读取缺陷。在 flush_to_ldisc 函数中存在内存泄漏时，用户使用 ioctls TIOCSPTLCK 和 TIOCGPTPEER 以及 TIOCSTI 和 TCXONC 触发争用条件时会发生此问题。此缺陷会让本地用户导致系统崩溃或从内存读取未经授权的随机数据。 (CVE-2022-1462)

  - 已修复 Linux 内核中的下列漏洞：can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks. (CVE-2022-49269)

  - 已修复 Linux 内核中的下列漏洞：tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ----
    ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key);
    lock(&port->lock); lock(console_owner); As commit dbdda842fe96 (printk: Add console owner and waiter logic to load balance console writes) said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted
    ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock:
    ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
    tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key);
    call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
    vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated--- (CVE-2022-49441)

  - 已修复 Linux 内核中的下列漏洞：list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
    Commit bf3b9f6372c4 (epoll: Add busy poll support to epoll with socket fds.) added the first lockless ep_events_available(), and commit c5a282e9635e (fs/epoll: reduce the scope of wq lock in epoll_wait()) made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 (epoll: eliminate unnecessary lock for zero timeout) made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted:
    G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 (CVE-2022-49443)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程的 Debian 12 主机安装了受多个漏洞影响的包，正如 dsa-6243 公告中提到的。

    - ------------------------------------------------------------------------- Debian 安全咨询 DSA-6243-1 security@debian.org https://www.debian.org/security/Salvatore Bonaccorso 2026年5月1日 https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    程序包：linux CVE ID：CVE-2023-53228 CVE-2023-53510 CVE-2023-53545 CVE-2024-47736 CVE-2024-47809 CVE-2024-49998 CVE-2024-50298 CVE-2024-56719 CVE-2025-21676 CVE-2025-21682 CVE-2025-37945 CVE-2025-37980 CVE-2025-38105 CVE-2025-38162 CVE-2025-38192 CVE-2025-38250 CVE-2025-38303 CVE-2025-38436 CVE-2025-38626 CVE-2025-38659 CVE-2025-38704 CVE-2025-39748 CVE-2025-39764 CVE-2025-39863 CVE-2025-40005 CVE-2025-40016 CVE-2025-40135 CVE-2025-40219 CVE-2025-40242 CVE-2025-40261 CVE-2025-40358 CVE-2025-68206 CVE-2025-68239 CVE-2025-68265 CVE-2025-71067 CVE-2025-71161 CVE-2025-71221 CVE-2025-71265 CVE-2025-71266 CVE-2025-71267 CVE-2025-71269 CVE-2026-23100 CVE-2026-23113 CVE-2026-23141 CVE-2026-23154 CVE-2026-23157 CVE-2026-23204 CVE-2026-23227 CVE-2026-23231 CVE-2026-23242 CVE-2026-23243 CVE-2026-23245 CVE-2026-23253 CVE-2026-23270 CVE-2026-23271 CVE-2026-23273 CVE-2026-23274 CVE-2026-23277 CVE-2026-23279 CVE-2026-23281 CVE-2026-23284 CVE-2026-23286 CVE-2026-23287 CVE-2026-23289 CVE-2026-23290 CVE-2026-23291 CVE-2026-23292 CVE-2026-23293 CVE-2026-23296 CVE-2026-23298 CVE-2026-23300 CVE-2026-23303 CVE-2026-23304 CVE-2026-23306 CVE-2026-23307 CVE-2026-23312 CVE-2026-23315 CVE-2026-23317 CVE-2026-23318 CVE-2026-23319 CVE-2026-23321 CVE-2026-23324 CVE-2026-23335 CVE-2026-23336 CVE-2026-23339 CVE-2026-23340 CVE-2026-23343 CVE-2026-23351 CVE-2026-23352 CVE-2026-23356 CVE-2026-23357 CVE-2026-23359 CVE-2026-23362 CVE-2026-23364 CVE-2026-23365 CVE-2026-23367 CVE-2026-23368 CVE-2026-23370 CVE-2026-23372 CVE-2026-23378 CVE-2026-23379 CVE-2026-23381 CVE-2026-23382 CVE-2026-23388 CVE-2026-23391 CVE-2026-23392 CVE-2026-23395 CVE-2026-23396 CVE-2026-23397 CVE-2026-23398 CVE-2026-23401 CVE-2026-23414 CVE-2026-23420 CVE-2026-23422 CVE-2026-23426 CVE-2026-23428 CVE-2026-23434 CVE-2026-23438 CVE-2026-23439 CVE-2026-23446 CVE-2026-23449 CVE-2026-23450 CVE-2026-23452 CVE-2026-23454 CVE-2026-23455 CVE-2026-23456 CVE-2026-23457 CVE-2026-23458 CVE-2026-23460 CVE-2026-23462 CVE-2026-23463 CVE-2026-23474 CVE-2026-23475 CVE-2026-31389 CVE-2026-31391 CVE-2026-31392 CVE-2026-31393 CVE-2026-31396 CVE-2026-31399 CVE-2026-31400 CVE-2026-31402 CVE-2026-31403 CVE-2026-31405 CVE-2026-31408 CVE-2026-31409 CVE-2026-31411 CVE-2026-31412 CVE-2026-31414 CVE-2026-31415 CVE-2026-31416 CVE-2026-31417 CVE-2026-31418 CVE-2026-31421 CVE-2026-31422 CVE-2026-31423 CVE-2026-31424 CVE-2026-31425 CVE-2026-31426 CVE-2026-31427 CVE-2026-31428 CVE-2026-31431 CVE-2026-31433 CVE-2026-31434 CVE-2026-31441 CVE-2026-31446 CVE-2026-31447 CVE-2026-31448 CVE-2026-31450 CVE-2026-31452 CVE-2026-31453 CVE-2026-31454 CVE-2026-31455 CVE-2026-31464 CVE-2026-31466 CVE-2026-31467 CVE-2026-31469 CVE-2026-31473 CVE-2026-31476 CVE-2026-31477 CVE-2026-31478 CVE-2026-31480 CVE-2026-31483 CVE-2026-31485 CVE-2026-31492 CVE-2026-31494 CVE-2026-31495 CVE-2026-31496 CVE-2026-31497 CVE-2026-31498 CVE-2026-31503 CVE-2026-31504 CVE-2026-31507 CVE-2026-31508 CVE-2026-31509 CVE-2026-31510 CVE-2026-31512 CVE-2026-31515 CVE-2026-31518 CVE-2026-31519 CVE-2026-31520 CVE-2026-31521 CVE-2026-31522 CVE-2026-31523 CVE-2026-31524 CVE-2026-31533 CVE-2026-31540 CVE-2026-31545 CVE-2026-31546 CVE-2026-31548 CVE-2026-31549 CVE-2026-31550 CVE-2026-31551 CVE-2026-31552 CVE-2026-31555 CVE-2026-31563 CVE-2026-31565 CVE-2026-31566 CVE-2026-31570 CVE-2026-31628 CVE-2026-31634 CVE-2026-31649 CVE-2026-31651 CVE-2026-31656 CVE-2026-31657 CVE-2026-31658 CVE-2026-31659 CVE-2026-31660 CVE-2026-31661 CVE-2026-31662 CVE-2026-31664 CVE-2026-31665 CVE-2026-31667 CVE-2026-31668 CVE-2026-31669 CVE-2026-31670 CVE-2026-31671 CVE-2026-31672 CVE-2026-31674 CVE-2026-31678 CVE-2026-31679 CVE-2026-31680 CVE-2026-31682 CVE-2026-31683 CVE-2026-31689 CVE-2026-31695 CVE-2026-31720 CVE-2026-31721 CVE-2026-31726 CVE-2026-31728 CVE-2026-31737 CVE-2026-31738 CVE-2026-31747 CVE-2026-31748 CVE-2026-31749 CVE-2026-31751 CVE-2026-31752 CVE-2026-31754 CVE-2026-31755 CVE-2026-31756 CVE-2026-31758 CVE-2026-31759 CVE-2026-31761 CVE-2026-31762 CVE-2026-31763 CVE-2026-31768 CVE-2026-31770 CVE-2026-31773 CVE-2026-31776 CVE-2026-31778 CVE-2026-31779 CVE-2026-31780 CVE-2026-31781 CVE-2026-31786 CVE-2026-31787 CVE-2026-31788 CVE-2026-43011 CVE-2026-43013 CVE-2026-43014 CVE-2026-43015 CVE-2026-43017 CVE-2026-43018 CVE-2026-43020 CVE-2026-43023 CVE-2026-43024 CVE-2026-43025 CVE-2026-43026 CVE-2026-43027 CVE-2026-43028 CVE-2026-43030 CVE-2026-43032 CVE-2026-43033 CVE-2026-43035 CVE-2026-43037 CVE-2026-43038 CVE-2026-43040 CVE-2026-43041 CVE-2026-43043 CVE-2026-43046 CVE-2026-43047 CVE-2026-43050 CVE-2026-43051 CVE-2026-43054 CVE-2026-43057

    在 Linux 内核中发现多个可能导致权限升级、拒绝服务或信息泄漏的漏洞。

    对于旧稳定发行版本 (bookworm)，已在版本 6.1.170-1 中修复这些问题。

    建议您升级 linux 程序包。

    如需了解 linux 的详细安全状态，请参阅其安全跟踪页面：
    https://security-tracker.debian.org/tracker/linux

    有关 Debian 安全公告、如何将这些更新应用到系统以及常见问题解答的更多信息，请访问以下网址：https://www.debian.org/security/

    邮件列表：debian-security-announce@lists.debian.org

Tenable 已直接从 Debian 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Oracle Linux 10 / 9 主机上存在安装的程序包该程序包受到 ELSA-2025-20530 公告中提及的多个漏洞的影响。

    - sunrpc在 svc auth 处理期间将 SVC_GARBAGE 处理为认证错误 (Jeff Layton) [Orabug: 38137447] {CVE-2025-38089}
    - 添加 Zen34 客户端 (Borislav Petkov (AMD)) [Orabug38172252] {CVE-2024-36350} {CVE-2024-36357}
    - x86/process在 MONITOR 之前移动缓冲区清除 (Kim Phillips) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}
    - 添加正常计数器 (Borislav Petkov (AMD)) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}
    - KVMSVM向客户机公告 TSA CPUID 位 (Borislav Petkov (AMD)) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}
    - x86/缺陷添加临时计划程序攻击缓解 (Borislav Petkov (AMD)) [Orabug: 38172252] {CVE-2024-36350} {CVE-2024-36357}

Tenable 已直接从 Oracle Linux 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
242344	Ubuntu 22.04 LTS：Linux 内核 (HWE) 漏洞 (USN-7653-1)	Nessus	Ubuntu Local Security Checks	2025/7/18	2025/7/18	high
240564	Ubuntu 22.04 LTS / 24.04 LTS：Linux kernel (Azure) 漏洞 (USN-7596-1)	Nessus	Ubuntu Local Security Checks	2025/6/26	2025/6/26	high
311783	Debian dla-4561 ： linux-config-6.1 - 安全更新	Nessus	Debian Local Security Checks	2026/5/2	2026/5/9	high
234757	Ubuntu 24.04 LTS / 24.10：Linux kernel 漏洞 (USN-7445-1)	Nessus	Ubuntu Local Security Checks	2025/4/23	2025/4/23	high
360724	AlmaLinux 9.6 [TuxCare] 安全更新：kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1779434490）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/2	high
360889	Rocky Linux 9.6 [TuxCare] 安全更新：kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1779434490）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/2	high
230359	Linux Distros 未修补的漏洞：CVE-2025-21682	Nessus	Misc.	2025/3/6	2026/11/13	medium
242347	Oracle Linux 9：Unbreakable Enterprise 内核 (ELSA-2025-20480)	Nessus	Oracle Linux Local Security Checks	2025/7/18	2026/2/9	medium
240566	Ubuntu 22.04 LTS / 24.04 LTS：Linux kernel 漏洞 (USN-7595-1)	Nessus	Ubuntu Local Security Checks	2025/6/26	2025/7/24	high
234778	Ubuntu 24.04 LTS / 24.10：Linux kernel 漏洞 (USN-7448-1)	Nessus	Ubuntu Local Security Checks	2025/4/23	2025/5/2	high
352871	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞（ALMALINUX9.2：CLSA-2026：1783791447）	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/10/22	low
311547	Debian dsa-6243 ： affs-modules-6.1.0-44-4kc-malta-di - 安全更新	Nessus	Debian Local Security Checks	2026/5/2	2026/5/8	high
252244	Oracle Linux 10 / 9Unbreakable Enterprise 内核 (ELSA-2025-20530)	Nessus	Oracle Linux Local Security Checks	2025/8/19	2026/2/9	medium

检测

插件搜索

high

high

high

high

high

high

medium

medium

high

high

low

high

medium