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

  - idpf修复加载时 init_task 中的错误处理如果 init_task 在驱动程序加载期间失败我们最终会没有 vports 和 netdev从而导致整个进程失败。在该状态下，当服务任务尝试访问未初始化的资源时，后续的重置将导致崩溃。以下跟踪来自 init_task 中的一个错误其中 CREATE_VPORT (op 501) 被 FW 拒绝[40922.763136] idpf 0000:83:00.0发起的设备 HW 重置 [40924.449797] idpf 0000:83:00.0: 事务失败(op 501) [40958.148190] idpf 0000:83:00.0检测到 HW 重置 [40958.161202] BUG内核空指针取消引用地址00000000000000a8 ... [40958.168094] Workqueueidpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf] [40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf] ... [40958.177932] 调用跟踪
    [40958.178491] <TASK> [40958.179040] process_one_work+0x226/0x6d0 [40958.179609] worker_thread+0x19e/0x340 [40958.180158] ? __pfx_worker_thread+0x10/0x10 [40958.180702] kthread+0x10f/0x250 [40958.181238] ?
    __pfx_kthread+0x10/0x10 [40958.181774] ret_from_fork+0x251/0x2b0 [40958.182307] ? __pfx_kthread+0x10/0x10 [40958.182834] ret_from_fork_asm+0x1a/0x30 [40958.183370] </TASK> 修复 init_task 中的错误处理以确保在加载期间发生错误时服务和邮箱任务被禁用。这些在 idpf_vc_core_init() 中启动将生成 init_task 并且无法知道其是否失败。如果成功加载驱动程序后重置时发生错误任务仍可运行因为这将允许 netdevs 尝试通过另一次重置进行恢复。以任何方式停止 PTP 回调因为在成功重置期间这些回调将通过对 idpf_vc_core_init() 的调用来重新启动。 (CVE-2026-23017)

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

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

  - 已修复 Linux 内核中的下列漏洞：udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. (CVE-2022-48946)

  - 已修复 Linux 内核中的下列漏洞：xen/privcmd: fix error exit of privcmd_ioctl_dm_op() The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case pages being NULL, and by checking the number of pages pinned by pin_user_pages_fast() matching the expected number of pages. (CVE-2022-49989)

  - 已修复 Linux 内核中的下列漏洞：platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]() The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method() is not freed after the call, so it leads to memory leak. The method results in ACPI buffer is not used, so just pass NULL to wmi_evaluate_method() which fixes the memory leak. (CVE-2022-50521)

  - 已修复 Linux 内核中的下列漏洞：net: USB: Fix wrong-direction WARNING in plusb.c The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU:
    1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
    __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag. (CVE-2023-52742)

  - 已修复 Linux 内核中的下列漏洞：tracing: Make sure trace_printk() can output as soon as it can be used Currently trace_printk() can be used as soon as early_trace_init() is called from start_kernel(). But if a crash happens, and ftrace_dump_on_oops is set on the kernel command line, all you get will be: [ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6 This is because the trace_printk() event (type 6) hasn't been registered yet. That gets done via an early_initcall(), which may be early, but not early enough. Instead of registering the trace_printk() event (and other ftrace events, which are not trace events) via an early_initcall(), have them registered at the same time that trace_printk() can be used. This way, if there is a crash before early_initcall(), then the trace_printk()s will actually be useful. (CVE-2023-53007)

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

远程 Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS 主机上安装的软件包存在多个漏洞，如 USN-8669-1 告警中所述。

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

    - UDP 上的 Foo-over-UDP （FOU）;

    - ARM64 架构；

    - x86 架构；

    - 区块层子系统；

    - 驱动程序核心；

    - Null 块设备驱动程序；

    - 蓝牙驱动程序；

    - 计数器接口驱动程序；

    - DMA 引擎子系统；

    - DPLL 子系统；

    - GPIO 子系统；

    - GPU 驱动程序；

    - I2C 子系统；

    - IIO ADC 驱动程序；

    - IIO 子系统；

    - InfiniBand 驱动程序；

    - 片上互连管理框架；

    - IOMMU 子系统；

    - IRQ 芯片驱动程序；

    - 模块化 ISDN 驱动程序；

    - LED 子系统；

    - 多设备驱动程序；

    - 媒体驱动程序；

    - UACCE 加速器框架；

    - MMC 子系统；

    - 以太网绑定驱动程序；

    - 网络驱动程序；

    - Mellanox 网络驱动程序；

    - Texas Instruments 网络驱动程序；

    - NVME 驱动程序；

    - 设备树和 Open Firmware 驱动程序；

    - PHY 驱动程序；

    - x86 平台驱动程序；

    - i.MX PM 域；

    - SCSI 子系统；

    - SLIMbus 驱动程序；

    - SPI 子系统；

    - TTY 驱动程序；

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

    - W1 Dallas 的 1-wire 总线驱动程序；

    - Xen 管理程序驱动程序；

    - BTRFS 文件系统；

    - EFI 变量文件系统；

    - 文件系统基础设施；

    - Ext4 文件系统；

    - FUSE（Userspace 中的文件系统）；

    - 网络文件系统库；

    - 网络文件系统 (NFS) 客户端；

    - 网络文件系统 (NFS) 服务器后台程序；

    - SMB 网络文件系统；

    - 内存管理；

    - 内存管理；

    - 计划程序基础设施；

    - 跟踪基础设施；

    - IPv4 联网；

    - Netfilter；

    - NFC 子系统；

    - 网络流量控制；

    - TCP 网络协议；

    - io_uring 子系统；

    - Perf 事件；

    - 锁定基元；

    - 休眠控制；

    - Timer 子系统；

    - BPF 子系统；

    - 浮动比例库；

    - 蓝牙子系统；

    - CAN 网络层；

    - Ceph Core 库；

    - Networking 核心；

    - IPv6 联网；

    - L2TP 协议；

    - MAC80211 子系统；

    - 多路径 TCP；

    - NET/ROM 层；

    - RxRPC 会话套接字；

    - SCTP 协议；

    - SMC 套接字；

    - VMware vSockets 驱动程序；

    - 无线网络；

    - ALSA AC97 驱动程序；

    - Creative Sound Blaster X-Fi 驱动程序；

    - Texas InstrumentS Audio (ASoC/HDA) 驱动程序；

    - USB音响设备;（CVE-2025-71158 ， ， ， CVE-2025-71161， CVE-2025-71162CVE-2026-22990CVE-2025-71199CVE-2025-71200CVE-2025-71190CVE-2025-71191CVE-2025-71189CVE-2025-71193CVE-2025-71192CVE-2025-71194CVE-2025-71195CVE-2025-71196CVE-2025-71197CVE-2025-71198CVE-2025-71188CVE-2026-22976CVE-2025-71201CVE-2026-22977CVE-2026-22978CVE-2026-22979CVE-2026-22980CVE-2026-22981CVE-2025-71187CVE-2026-22985CVE-2026-22982CVE-2026-22986CVE-2026-22987CVE-2026-22989CVE-2026-22991CVE-2026-22992CVE-2025-71186CVE-2026-22994CVE-2026-22993CVE-2026-23004CVE-2026-23003CVE-2026-23005CVE-2026-23002CVE-2026-23001CVE-2026-23000CVE-2026-23006CVE-2026-22999CVE-2026-22998CVE-2026-22997CVE-2026-23007CVE-2026-22996CVE-2025-71185CVE-2026-23008CVE-2026-23012CVE-2026-23011CVE-2026-23013CVE-2026-23010CVE-2026-23014CVE-2026-23015CVE-2025-71163CVE-2025-71182CVE-2026-23017CVE-2025-71180CVE-2025-71183CVE-2025-71184CVE-2026-23009CVE-2025-71160、 、 、 CVE-2026-23059CVE-2026-23032CVE-2026-23031CVE-2026-23033CVE-2026-23034CVE-2026-23035CVE-2026-23036CVE-2026-23037CVE-2026-23030CVE-2026-23042CVE-2026-23038CVE-2026-23044CVE-2026-23045CVE-2026-23046CVE-2026-23047CVE-2026-23049CVE-2026-23026CVE-2026-23051CVE-2026-23050CVE-2026-23052CVE-2026-23053CVE-2026-23054CVE-2026-23055CVE-2026-23056CVE-2026-23025CVE-2026-23058CVE-2026-23057CVE-2026-23061CVE-2026-23062CVE-2026-23063CVE-2026-23072CVE-2026-23071CVE-2026-23070CVE-2026-23073CVE-2026-23069CVE-2026-23068CVE-2026-23067CVE-2026-23075CVE-2026-23066CVE-2026-23065CVE-2026-23064CVE-2026-23076CVE-2026-23024CVE-2026-23022CVE-2026-23086CVE-2026-23081CVE-2026-23085CVE-2026-23078CVE-2026-23079CVE-2026-23080CVE-2026-23084CVE-2026-23087CVE-2026-23023CVE-2026-23083CVE-2026-23021CVE-2026-23077CVE-2026-23020CVE-2026-23019CVE-2026-23018、 、 、 CVE-2026-23123CVE-2026-23099CVE-2026-23100CVE-2026-23101CVE-2026-23098CVE-2026-23103CVE-2026-23102CVE-2026-23104CVE-2026-23105CVE-2026-23106CVE-2026-23107CVE-2026-23108CVE-2026-23097CVE-2026-23110CVE-2026-23109CVE-2026-23113CVE-2026-23114CVE-2026-23115CVE-2026-23116CVE-2026-23118CVE-2026-23096CVE-2026-23120CVE-2026-23119CVE-2026-23121CVE-2026-23122CVE-2026-23124CVE-2026-23136CVE-2026-23135CVE-2026-23133CVE-2026-23137CVE-2026-23131CVE-2026-23130CVE-2026-23129CVE-2026-23138CVE-2026-23128CVE-2026-23126CVE-2026-23125CVE-2026-23139CVE-2026-23095CVE-2026-23093CVE-2026-23148CVE-2026-23144CVE-2026-23147CVE-2026-23141CVE-2026-23142CVE-2026-23143CVE-2026-23146CVE-2026-23150CVE-2026-23094CVE-2026-23145CVE-2026-23092CVE-2026-23140CVE-2026-23090CVE-2026-23089CVE-2026-23088、 、 、 CVE-2026-31636CVE-2026-23162CVE-2026-23163CVE-2026-23164CVE-2026-23165CVE-2026-23166CVE-2026-23167CVE-2026-23161CVE-2026-23169CVE-2026-23168CVE-2026-23170CVE-2026-23171CVE-2026-23172CVE-2026-23173CVE-2026-23212CVE-2026-23160CVE-2026-31414CVE-2026-31405CVE-2026-31444CVE-2026-31501CVE-2026-31589CVE-2026-46242CVE-2026-46137CVE-2026-46113CVE-2026-46290CVE-2026-43499CVE-2026-43465CVE-2026-43379CVE-2026-46317CVE-2026-43198CVE-2026-31705CVE-2026-31633CVE-2026-46331CVE-2026-23159CVE-2026-23157CVE-2026-53277CVE-2026-53176CVE-2026-53228CVE-2026-52989CVE-2026-53086CVE-2026-53131CVE-2026-53225CVE-2026-53359CVE-2026-23158CVE-2026-53212CVE-2026-23156CVE-2026-52924CVE-2026-23154CVE-2026-23152CVE-2026-23151

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

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

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

  - 已修复 Linux 内核中的下列漏洞：udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. (CVE-2022-48946)

  - 已修复 Linux 内核中的下列漏洞：xen/privcmd: fix error exit of privcmd_ioctl_dm_op() The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case pages being NULL, and by checking the number of pages pinned by pin_user_pages_fast() matching the expected number of pages. (CVE-2022-49989)

  - 已修复 Linux 内核中的下列漏洞：platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]() The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method() is not freed after the call, so it leads to memory leak. The method results in ACPI buffer is not used, so just pass NULL to wmi_evaluate_method() which fixes the memory leak. (CVE-2022-50521)

  - 已修复 Linux 内核中的下列漏洞：net: USB: Fix wrong-direction WARNING in plusb.c The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU:
    1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [inline] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline] pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
    __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl+0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and remove the USB_DIR_IN flag. (CVE-2023-52742)

  - 已修复 Linux 内核中的下列漏洞：tracing: Make sure trace_printk() can output as soon as it can be used Currently trace_printk() can be used as soon as early_trace_init() is called from start_kernel(). But if a crash happens, and ftrace_dump_on_oops is set on the kernel command line, all you get will be: [ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6 This is because the trace_printk() event (type 6) hasn't been registered yet. That gets done via an early_initcall(), which may be early, but not early enough. Instead of registering the trace_printk() event (and other ftrace events, which are not trace events) via an early_initcall(), have them registered at the same time that trace_printk() can be used. This way, if there is a crash before early_initcall(), then the trace_printk()s will actually be useful. (CVE-2023-53007)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
297487	Linux Distros 未修补的漏洞：CVE-2026-23017	Nessus	Misc.	2026/1/31	2026/10/12	medium
359640	AlmaLinux 9.6 [TuxCare] 安全更新：kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1782155469）	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/15	high
340678	Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS：Linux 内核（NVIDIA）漏洞（USN-8669-1）	Nessus	Ubuntu Local Security Checks	2026/8/26	2026/9/23	high
359694	Rocky Linux 9.6 [TuxCare] 安全更新：kernel / kernel-abi-stablelists / kernel-core / 等多个漏洞（ALMALINUX9.6：CLSA-2026：1782155469）	Nessus	Rocky Linux Local Security Checks	2026/10/1	2026/10/15	high

检测

插件搜索

medium

high

high

high