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

  - usbcdns3将 cdns 集活动部分放在旋转锁之外。在恢复过程中可能会计划设备因此这不能出现在原子操作中。由于 pm_runtime_set_active 将恢复供应商请将 set active 在旋转锁定之外放置仅用于保护 struct cdns 数据结构否则内核将报告以下警告缺陷从 drivers/base/power/ 的无效上下文调用的休眠函数runtime.c:1163 in_atomic(): 1、irqs_disabled(): 0、non_block: 0、pid: 651、名称: sh preempt_count: 1、预期: 0 RCU 嵌套深度: 0、预期: 0 CPU: 0 PID: 651 Commsh TaintedG WC 6.1.20 #1 硬件名称Freescale i.MX8QM MEK (DT) 调用跟踪
    dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x64/0x80 dump_stack+0x1c/0x38
    __might_resched+0x1fc/0x240 __might_sleep+0x68/0xc0 __pm_runtime_resume+0x9c/0xe0 rpm_get_suppliers+0x68/0x1b0 __pm_runtime_set_status+0x298/0x560 cdns_resume+0xb0/0x1c0 cdns3_controller_resume.isra.0+0x1e0/0x250 cdns3_plat_resume+0x28/0x40 (CVE-2023-53287)

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

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

  - mtdmappxa2xx-flash修复重映射错误时探测释放“info”中的内存泄漏以避免内存泄漏。
    [<miquel.raynal@bootlin.com>改写提交日志] (CVE-2022-50324

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

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

  - nubus部分恢复 proc_create_single_data() 转换 至 proc_create_single_data() 的转换引入了回归据此读取 /proc/bus/nubus 中的文件会导致段错误# grep -r 。
    /proc/bus/nubus/e/ Super Data 中 0x00000020 处的数据读取错误 (pc=0x1074c2) 错误 KERNEL BUSERR 错误
    中链接的 00000000 ModulesPC: [<001074c2>] PDE_DATA+0xc/0x16 SR: 2010 SP: 38284958 a2: 01152370 d0
    00000001 d1: 01013000 d2: 01002790 d3 daddr=00000020 dobuf=01199e70 baddr=001074c8 dibuf=ffffffff : 00000000 d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40 进程 grep (pid: 45、 task=142f8727) Frame format=4 ver=4ver=074d isc=2008ce2e a0: 00000000 a1: 00222a40 Stack from 01199e48: 01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000 00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000 d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000 00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640 011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c 000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0 调用跟踪 [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0 [<000d551a>] seq_read+0xc4/0x510 [<00018000>] fp_fcos+0x2/0x82 [<0002800d>] __sys_setreuid+0x115/0x1c6 [<00103640>] proc_reg_read+0xb05c/0xb05c/ [<00018000>] fp_fcos+0x2/0x82 [<000b3344>] __vfs_read+0x2c/0x13c [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b8aa2>] sys_statx+0x60/0x7e [<000b34b6>] vfs_read +0x62/0x12a [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b39c2>] ksys_read+0x48/0xbe [<00018000>] fp_fcos+0x2/0x82 [<000b3a4e>] sys_read+0x16/0x1a [<00018000>] fp_fcos+0x2/0x82 [<00002b84>] syscall+0x8/0xc [<00018000>] fp_fcos +0x2/0x82 [<0000c016>] not_ext+0xa/0x18 Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8 Disabling lock debugging due to kernel taint Segmentation fault The proc_create_single_data() 转换不起作用因为 single_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) 与原始代码不同。 (CVE-2023-53217)

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

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

  - 已修复 Linux 内核中的下列漏洞：firmware: stratix10-svc: Fix a potential resource leak in svc_create_memory_pool() svc_create_memory_pool() is only called from stratix10_svc_drv_probe(). Most of resources in the probe are managed, but not this memremap() call. There is also no memunmap() call in the file. So switch to devm_memremap() to avoid a resource leak.
    (CVE-2023-53255)

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

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

  - androidbinder停止保存指向 VMA 的指针不记录指向 mmap_lock 之外的 VMA 的指针以供以后使用。这样做是不安全的并且在设置期间释放记录的 VMA 指针*之后*之后存在许多失败路径。没有对驱动程序的回调以从通用 mm 代码中清除已保存的指针。此外如果任意数量的 VMA 操作最终释放 VMA那么 VMA 指针可能会变得过时因此对其进行保存非常容易受到影响。而是更改 binder_alloc struct 以记录 VMA 的起始地址并在需要时使用 vma_lookup() 获取 vma。在 vma 指针的更新中添加 lockdep mmap_lock 检查以确保保持锁定并依靠该锁定来实现读取和写入的同步无论如何已经如此因此不需要 smp_wmb()/smp_rmb()。
    [akpm@linux-foundation.org修复 drivers/android/binder_alloc_selftest.c] (CVE-2022-50240)

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

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

  - 已修复 Linux 内核中的下列漏洞：sctp: handle the error returned from sctp_auth_asoc_init_active_key When it returns an error from sctp_auth_asoc_init_active_key(), the active_key is actually not updated. The old sh_key will be freeed while it's still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot:
    sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 This patch is to fix it by not replacing the sh_key when it returns errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key(). For sctp_auth_set_active_key(), old active_key_id will be set back to asoc->active_key_id when the same thing happens. (CVE-2022-50243)

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

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

  - ubi确保 VID 标头偏移 + VID 标头大小 <= alloc, 大小确保 VID 标头偏移 + VID 标头大小不超过分配的区域以避免碎片 OOB。BUGKASANcrc32_body lib/crc32.c:111 中存在 slab 越界 [内联] 缺陷KASANcrc32_le_generic lib/crc32.c:179 中存在 slab 越界 [内联] BUG: KASAN crc32_le_base+0x58c/0x626 lib/crc32.c:197 中通过任务 syz-executor136/1555 CPU: 2 PID1555 Commsyz-executor136 感染的 GW 在地址 ffff88802bb36f00 进行大小 4 的读取发生 slab 越界 6.0.0-1868 #1 硬件名称Red Hat KVM、BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 04/01/2014 调用跟踪 <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x85/0xad lib /dump_stack.c:106 print_address_description mm/kasan/report.c:317 [内联] print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433 kasan_report+0xa7/0x11b mm/kasan/report.c 495 crc32_body lib/crc32.c:111 [内联] crc32_le_generic lib/crc32.c:179 [内联] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c 1067 create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0 x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 驱动程序/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [内联] __do_sys_ioctl fs/ioctl.c:870 [内联] __se_sys_ioctl fs/ioctl.c:856 [内联] __x64_sys_ioctl+0x193/0x213 fs/ ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 RIP: 0033:0x7f96d5cf753d Code：RSP 002b：00007fffd72206f8 EFLAGS
    00000246 ORIG_RAX0000000000000010 RAXffffffffffffffda RBX0000000000000000 RCX00007f96d5cf753d RDX
    0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003 RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 R13:
    00007fffd72207e0 R140000000000000000 R150000000000000000 </TASK> 由任务 1555 分配
    kasan_save_stack+0x20/0x3d mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [内联] set_alloc_info mm/kasan/common.c:437 [内联]____kasan_kmalloc mm/kasan/common.c:516 [内联]
    __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525 kasan_kmalloc include/linux/kasan.h:234 [内联]
    __kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc include/linux/slab.h:605 [inline] ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline] create_vtbl+0xcc/0x9c4 drivers/mtd/ubi /vtbl.c:295 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [内联] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach。 c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl .c:870 [内联] __se_sys_ioctl fs/ioctl.c:856 [内联]
    __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [内联] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0地址属于 ffff88802bb36e00 的对象该对象属于大小 256 的缓存 kmalloc-256 有缺陷的地址位于距离 256 字节区域右侧 0 字节 [ffff88802bb36e00、ffff88802bb36f00] 有缺陷的地址属于物理页 page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2bb36 head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 flags0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw
    000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40 raw: 0000000000000000 00000000001
    ---truncated--- (CVE-2023-53265)

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

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

  - io_uring/af_unix将已注册文件的 gc 推迟到 io_uring 版本我们希望由 io_uring 本身完成操作而不是将 io_uring 已注册的文件放入 unix_gc()。此处的技巧是考虑 io_uring 注册的文件进行循环检测但不实际将其放置。由于 io_uring 无法注册其他 ring 实例因此这将删除对 ring 文件的所有引用从而触发 ->release 路径并通过 io_ring_ctx_free() 进行清理。 [axboe将 kerneldoc 注释添加到 skb包含在 skb 泄漏补丁中] (CVE-2022-50234)

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

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

  - atmatmtcp防止 atmtcp_recv_control() 中的任意写入。 syzbot 报告了以下错误消息。 [0] 通过 connect() 或 close() 调用 atmtcp_v_open() 或 atmtcp_v_close() 时会调用 atmtcp_send_control() 以发送内核内特殊消息。该消息在 atmtcp_control.hdr.length 中具有 ATMTCP_HDR_MAGIC。此外struct atm_vcc 的指针会设置为 atmtcp_control.vcc。值得注意的是 struct atmtcp_control 是 uAPI但具有用于内核指针的空间。 struct atmtcp_control { struct atmtcp_hdr hdr; /* 必须为第一个
    */ ... atm_kptr_t vcc; /* 两个方向 */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; }
    __ATM_API_ALIGN atm_kptr_t;特殊消息在 atmtcp_c_send() 调用的 atmtcp_recv_control() 中进行处理。 atmtcp_c_send() 为 vcc->dev->ops->send() 从 2 条路径调用1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg() 问题为 sendmsg () 不验证消息长度用户空间可滥用 atmtcp_recv_control() 覆盖 atmtcp_control 编制的任何 kptr。我们添加一个新的 ->pre_send() 挂钩以验证来自 sendmsg() 的消息。 [0]Oops一般保护错误可能是非规范地址 0xdffffc00200000ab0000 [#1] SMP KASAN PTI KASAN可能是 user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Commsyz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) 硬件名称Google Google 计算引擎/Google 计算引擎、BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/ atm/atmtcp.c:93 [内联] RIP0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 代码4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 00 00 4c 89 f0 48 c1 e8 03 EFLAGS00010203 RAX
    00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10:
     R11dffffc0000000000  : ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg +0x505/0x830 net/socket.c:2614
    ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [内联] __do_sys_sendmsg net/socket.c:2705 [内联] __se_sys_sendmsg net/socket.c:2703 [内联] __x64_sys_sendmsg+0x169b net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 代码28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d ff 01 ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP
    002b00007f8d7e923198 EFLAGS00000246 ORIG_RAX000000000000002e RAXffffffffffffffda RBX
    00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11:
    0000000000000246 R1200007f8d7e9c10ac R1300007f8d7e9231a0 R140000200000000200 R150000200000000250 </TASK> 中链接的模块(CVE-2025-39828)

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

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

  - 已修复 Linux 内核中的下列漏洞：clk: socfpga: Fix memory leak in socfpga_gate_init() Free @socfpga_clk and @ops on the error path to avoid memory leak issue.
    (CVE-2022-50264)

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

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

  - pstore/ram检查 init 期间空 prz 的开头提交 30696378f68a 之后pstore/ram不将空缓冲区视为有效初始化在看到 buffer_size 为零之后无论缓冲区开始位置如何初始化都会假设 prz 有效。这种未经检查的初始值意味着它可能超出缓冲区的边界，从而导致未来在写入时发生访问错误sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78
    __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 ... 若要避免此问题请在初始化阶段期间同时检查 prz 开头是否为 0。如果不是这样下一个 prz 健全性检查情况将发现它开始 > 大小并将缓冲区恢复到正常状态。 [kees使用回溯和说明更新提交日志] (CVE-2023-53331)

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

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

  - wifiiwl3945添加对 create_singlethread_workqueue 缺少的检查 对 create_singlethread_workqueue 的返回值添加检查以避免空指针取消引用。 (CVE-2023-53277)

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

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

  - io_uring/kbuf修复 this_len 计算中的符号性当导入和使用缓冲区时buf->len 被视为无符号。但是提交时 buf->len 会转换为 signed int。如果缓冲区大到足以被解释为负值这可导致非预期行为。使 min_t 计算不签名。 (CVE-2025-39822)

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

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

  - 已修复 Linux 内核中的下列漏洞：driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event() The kfree() should be called when memory fails to be allocated for cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be a memory leak, so add kfree() to fix it. (CVE-2023-53267)

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

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

  - 已修复 Linux 内核中的下列漏洞：HID: intel-thc-hid: intel-thc: Fix incorrect pointer arithmetic in I2C regs save Improper use of secondary pointer (&dev->i2c_subip_regs) caused kernel crash and out-of-bounds error: BUG: KASAN: slab-out-of-bounds in
    _regmap_bulk_read+0x449/0x510 Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107 CPU: 3 UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary) Workqueue: async async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x660 ?
    __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x26/0x200 kasan_report+0xe1/0x120 ? _regmap_bulk_read+0x449/0x510 ? _regmap_bulk_read+0x449/0x510
    __asan_report_store4_noabort+0x17/0x30 _regmap_bulk_read+0x449/0x510 ? __pfx__regmap_bulk_read+0x10/0x10 regmap_bulk_read+0x270/0x3d0 pio_complete+0x1ee/0x2c0 [intel_thc] ? __pfx_pio_complete+0x10/0x10 [intel_thc] ? __pfx_pio_wait+0x10/0x10 [intel_thc] ? regmap_update_bits_base+0x13b/0x1f0 thc_i2c_subip_pio_read+0x117/0x270 [intel_thc] thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc] ?
    __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc] [...] The buggy address belongs to the object at ffff888136005d00 which belongs to the cache kmalloc-rnd-12-192 of size 192 The buggy address is located 0 bytes to the right of allocated 192-byte region [ffff888136005d00, ffff888136005dc0) Replaced with direct array indexing (&dev->i2c_subip_regs[i]) to ensure safe memory access. (CVE-2025-39818)

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

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

  - 已修复 Linux 内核中的下列漏洞：hwmon: (pmbus_core) Fix NULL pointer dereference Pass i2c_client to _pmbus_is_enabled to drop the assumption that a regulator device is passed in. This will fix the issue of a NULL pointer dereference when called from _pmbus_get_flags.
    (CVE-2023-53206)

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

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

  - drm/client修复 drm_client_modeset_probe 中的内存泄漏当新模式设置为 modeset->mode 时应释放之前的模式。This fixes the following kmemleak report: drm_mode_duplicate+0x45/0x220 [drm] drm_client_modeset_probe+0x944/0xf50 [drm] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper] drm_client_register+0x169/0x240 [drm] ast_pci_probe+0x142 /0x190 [ast] local_pci_probe+0xdc/0x180 work_for_cpu_fn+0x4e/0xa0 process_one_work+0x8b7/0x1540 worker_thread+0x70a/0xed0 kthread+0x29f/0x340 ret_from_fork+0x1f/0x30 (CVE-2023-53288)

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

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

  - 已修复 Linux 内核中的下列漏洞：media: ov8865: Fix an error handling path in ov8865_probe() The commit in Fixes also introduced some new error handling which should goto the existing error handling path. Otherwise some resources leak. (CVE-2022-50254)

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

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

  - 因 Graphics: Canvas2D 组件中的释放后使用而导致沙盒逃逸。此漏洞会影响 Firefox < 143、Firefox ESR < 140.3、Thunderbird < 143 和 Thunderbird < 140.3。(CVE-2025-10527)

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

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

  - SVG 组件中的整数溢出。此漏洞会影响 Firefox < 143、Firefox ESR < 115.28、Firefox ESR < 140.3、Thunderbird < 143 和 Thunderbird < 140.3。(CVE-2025-10533)

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

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

  - nfsd调用 op_release即使 op_func 返回错误 对于具有普通回复的 opsnfsd4_encode_operation 将会快捷化大部分编码工作并跳至仅编组状态。
    它跳过的操作之一是调用 op_release。如果在不恰当的时间出现错误这可导致 layoutget 代码路径中的内存泄漏。让复合处理引擎始终调用 op_release即使 op_func 在 op->status 中设置了错误。通过此更改我们还需要 nfsd4_block_get_device_info_scsi 在出错时将 gd_device 指针设置为空以避免双重释放。
    (CVE-2023-53241)

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

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

  - pnode在源对等机上终止 propagate_mnt() 函数在创建挂载时处理挂载传播并将源挂载树 @source_mnt 传播到以 @dest_mnt 为首的目标传播挂载树的所有适用节点。遗憾的是它包含一个缺陷当查找源挂载的副本成为目标传播树中从属顶部挂载的源挂载树的主控时它无法在 @source_mnt 对等机终止从而导致空取消引用。
    一旦理解了缺陷的机制就很容易触发。由于存在非特权用户命名空间，该漏洞可供非特权用户使用。修复此缺陷时由于术语不明确或概念缺失多次发生混淆。首先我们先进行一些说明* 术语“主机”或“对等机”表示共享挂载。共享的挂载属于对等组。 * 对等组是一组互相传播的共享挂载。可通过对等组 id 对其进行识别。对等组 id 可在 @shared_mnt->mnt_group_id 中找到。同一对等组内的共享挂载具有相同的对等组 id。可通过 @shared_mnt->mnt_share 访问对等机组中的对等机。 * 术语“从属挂载”或“从属挂载”表示从对等组中的对等方接收传播传播的挂载。IOW共享挂载可具有从属挂载且从属挂载将共享挂载作为其主控。对等机组中给定对等机的从属挂载列于该对等机从属列表中，网址为 @shared_mnt->mnt_slave_list。 * 术语“主挂载”指对等组中的挂载。IOW表示共享挂载或对等群组中的对等挂载。术语“主挂载”或简称为“主挂载”主要用于在用于从主挂载接收传播信息的从属挂载的上下文中进行通信时。从属挂载的主控挂载可识别从属挂载从中接收传播的最近的对等组。从服务器的主服务器挂载可通过 @slave_mount->mnt_master 进行识别。不同的从服务器可能指向相同对等组中的不同主服务器。 * 对等组中的多个对等可以具有非空 ->mnt_slave_lists。对等机的非空 ->mnt_slave_lists 不相交。因此为确保对等组的所有从属挂载都能访问
    必须遍历对等组中所有对等机的 ->mnt_slave_lists。 * 从属挂载指向它们通过 @slave_mnt->mnt_master 接收传播的最近对等组中的对等机请参阅上文。它们与这些对等机一起组成了一个传播组（见下文）。因此，可通过对等机/主机（对等机挂载是从其接收传播）的对等机组 id @slave_mnt->mnt_master->mnt_group_id 识别最近的对等组。 * 共享从挂载是对等组 pg1 的从挂载同时也是另一个对等组 pg2 中的对等。因此，对等群组可从另一个对等群组接收 传播。如果对等组 pg1 是另一个对等组 pg2 的从属则对等组 pg1 中的所有对等机将通过 ->mnt_master 指向对等组 pg2 中的同一个对等机。IOW对等机群组 pg1 中的所有对等机出现在同一个 ->mnt_slave_list 中。
    IOW它们不能成为不同对等组的从属。 * 纯从挂载是指作为对等组的从属但不是另一个对等组中的对等机时的从挂载。 * 传播组是指由单个对等组 pg1 以及通过 ->mnt_master 指向该对等组中的对等组的所有从属挂载和共享从属挂载组成的挂载集。IOW所有从属挂载均使 @slave_mnt->mnt_master->mnt_group_id 等于 @shared_mnt->mnt_group_id。传播组的概念使讨论传播树中的单个传播级别变得更容易。例如在传播_mnt() 中@dest_mnt 的直接对等机以及 @dest_mnt 对等机组的所有从属形成传播组 pr ---truncated--- (CVE-2022-50280)

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

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

  - netfilterconntrackdccp将整个标头复制到堆栈缓冲区而不仅仅是基本的 Eric Dumazet 说
    nf_conntrack_dccp_packet() 具有唯一一个 dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh);根据内容，不会从数据包中“提取”更多内容。 dh->dccph_doff 和/或 dh->dccph_x ...因此 dccp_ack_seq() 可以正常读取越过 _dh 缓冲区的内容。缺陷KASAN任务 syz-executor.2/29371在 addr ffff000128f66e0c 执行的 nf_conntrack_dccp_packet+0x1134/0x11c0 大小为 4 的读取中发生堆栈越界 [..]额外的序列号和所有已知的 dccp 数据包类型标头然后在初始验证基本标头后再次拉取。同时将缺少 48 位序列位但 RFC 指定类型“必须使用”的数据包标记为无效。仅限编译测试。 v2第一个 skb_header_pointer() 现在需要调整大小以仅提取通用标头。(Eric) 请注意我打算在今年晚些时候删除 dccp conntrack 支持。
    (CVE-2023-53333)

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

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

  - md/raid10修复“r10bio->remaining”泄漏以进行恢复 raid10_sync_request() 将为 rdev 和替换 rdev 添加“r10bio->remaining”。但是如果读取 io 失败recovery_request_write() 将返回而不发出写入 io 在这种情况下end_sync_request() 只会被调用一次且“remaining”会泄露进而造成 io 挂起。根据“bio”和“repl_bio”是否有效通过减少“remaining”修复 问题。 (CVE-2023-53299)

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

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

  - 已修复 Linux 内核中的下列漏洞：xen/gntdev: Prevent leaking grants Prior to this commit, if a grant mapping operation failed partially, some of the entries in the map_ops array would be invalid, whereas all of the entries in the kmap_ops array would be valid. This in turn would cause the following logic in gntdev_map_grant_pages to become invalid: for (i = 0; i < map->count;
    i++) { if (map->map_ops[i].status == GNTST_okay) { map->unmap_ops[i].handle = map->map_ops[i].handle; if (!use_ptemod) alloced++; } if (use_ptemod) { if (map->kmap_ops[i].status == GNTST_okay) { if (map->map_ops[i].status == GNTST_okay) alloced++; map->kunmap_ops[i].handle = map->kmap_ops[i].handle; } }} ... atomic_add(alloced, &map->live_grants); Assume that use_ptemod is true (i.e., the domain mapping the granted pages is a paravirtualized domain). In the code excerpt above, note that the alloced variable is only incremented when both kmap_ops[i].status and map_ops[i].status are set to GNTST_okay (i.e., both mapping operations are successful). However, as also noted above, there are cases where a grant mapping operation fails partially, breaking the assumption of the code excerpt above. The aforementioned causes map->live_grants to be incorrectly set. In some cases, all of the map_ops mappings fail, but all of the kmap_ops mappings succeed, meaning that live_grants may remain zero. This in turn makes it impossible to unmap the successfully grant-mapped pages pointed to by kmap_ops, because unmap_grant_pages has the following snippet of code at its beginning: if (atomic_read(&map->live_grants) == 0) return; /* Nothing to do */ In other cases where only some of the map_ops mappings fail but all kmap_ops mappings succeed, live_grants is made positive, but when the user requests unmapping the grant-mapped pages,
    __unmap_grant_pages_done will then make map->live_grants negative, because the latter function does not check if all of the pages that were requested to be unmapped were actually unmapped, and the same function unconditionally subtracts data->count (i.e., a value that can be greater than map->live_grants) from map->live_grants. The side effects of a negative live_grants value have not been studied. The net effect of all of this is that grant references are leaked in one of the above conditions. In Qubes OS v4.1 (which uses Xen's grant mechanism extensively for X11 GUI isolation), this issue manifests itself with warning messages like the following to be printed out by the Linux kernel in the VM that had granted pages (that contain X11 GUI window data) to dom0: g.e. 0x1234 still pending, especially after the user rapidly resizes GUI VM windows (causing some grant-mapping operations to partially or completely fail, due to the fact that the VM unshares some of the pages as part of the window resizing, making the pages impossible to grant-map from dom0). The fix for this issue involves counting all successful map_ops and kmap_ops mappings separately, and then adding the sum to live_grants. During unmapping, only the number of successfully unmapped grants is subtracted from live_grants. The code is also modified to check for negative live_grants values after the subtraction and warn the user. (CVE-2022-50257)

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

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

  - trace/fgraph修复由缺少取消注册通知程序引起的警告此警告在 v6.16 上测试期间触发了通知程序回调 ftrace_suspend_notifier_call 已注册警告CPU2 PID
    86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... 调用跟踪 <TASK> locking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f 写入 function_profile_enabled 接口时在 start_graph_tracing 失败后未取消注册通知器导致下次写入 function_profile_enabled 时发出警告。已通过在异常路径中添加 unregister_pm_notifier 进行修复。 (CVE-2025-39829)

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

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

  - 已修复 Linux 内核中的下列漏洞：erofs: fix order >= MAX_ORDER warning due to crafted negative i_size As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly. Let's fall back to the generic path to deal with such unusual i_size. [1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com (CVE-2022-50313)

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

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

  - 已修复 Linux 内核中的下列漏洞：drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs When (size != 0 || ptrs->lvds_ entries != 3), the program tries to free() the ptrs.
    However, the ptrs is not created by calling kzmalloc(), but is obtained by pointer offset operation. This may lead to memory leaks or undefined behavior. Fix this by replacing the arguments of kfree() with ptrs_block. (cherry picked from commit 7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec) (CVE-2022-50287)

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

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

  - mmcmoxart修复 mmc_add_host() 的返回值检查如果忽略其返回值mmc_add_host() 可能返回错误则在 mmc_alloc_host() 中分配的内存将泄漏并因删除未添加而导致内核崩溃删除路径中的设备。因此请通过检查返回值并转到将调用 mmc_free_host() 的错误路径来修复此问题。 (CVE-2022-50268)

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

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

  - 已修复 Linux 内核中的下列漏洞：net: do not sense pfmemalloc status in skb_append_pagefrags() skb_append_pagefrags() is used by af_unix and udp sendpage() implementation so far.
    In commit 326140063946 (tcp: TX zerocopy should not sense pfmemalloc status) we explained why we should not sense pfmemalloc status for pages owned by user space. We should also use skb_fill_page_desc_noacc() in skb_append_pagefrags() to avoid following KCSAN report: BUG: KCSAN: data-race in lru_add_fn / skb_append_pagefrags write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:323 [inline] lru_add_fn+0x327/0x410 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 lru_add_drain_cpu+0x73/0x250 mm/swap.c:669 lru_add_drain+0x21/0x60 mm/swap.c:773 free_pages_and_swap_cache+0x16/0x70 mm/swap_state.c:311 tlb_batch_pages_flush mm/mmu_gather.c:59 [inline] tlb_flush_mmu_free mm/mmu_gather.c:256 [inline] tlb_flush_mmu+0x5b2/0x640 mm/mmu_gather.c:263 tlb_finish_mmu+0x86/0x100 mm/mmu_gather.c:363 exit_mmap+0x190/0x4d0 mm/mmap.c:3098 __mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copy_process+0x19fc/0x2100 kernel/fork.c:2518 kernel_clone+0x166/0x550 kernel/fork.c:2671 __do_sys_clone kernel/fork.c:2812 [inline] __se_sys_clone kernel/fork.c:2796 [inline]
    __x64_sys_clone+0xc3/0xf0 kernel/fork.c:2796 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1817 [inline]
    __skb_fill_page_desc include/linux/skbuff.h:2432 [inline] skb_fill_page_desc include/linux/skbuff.h:2453 [inline] skb_append_pagefrags+0x210/0x600 net/core/skbuff.c:3974 unix_stream_sendpage+0x45e/0x990 net/unix/af_unix.c:2338 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1255
    __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline]
    __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed:
    0x0000000000000000 -> 0xffffea00058fc188 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 (CVE-2022-50323)

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

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

  - 由于 IP 地址值 0 未通过 isPublic 正确分类为可全局路由因此一直使用到 2.0.1 在 NPM 中的 ip又称为 node-ip程序包可能允许 SSRF。注意：存在此问题的原因是对 CVE-2024-29415 的修复不完整。注意在多个应用程序的当前版本中对 IP 地址 0 (解释为 0.0.0.0) 的连接尝试遭到 net::ERR_ADDRESS_INVALID 等错误消息阻断。
    但是在某些同时依赖于应用程序版本和操作系统的情况下对 0 和 0.0.0.0 的连接尝试被视为对 127.0.0.1 的连接尝试正因为此原因isPublic 的错误值会更好。 (CVE-2025-59437)

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

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

  - 在 NPM 中低于 2.0.1 的 ip又称为 node-ip程序包可能允许 SSRF因为 IP 地址值 017700000001 通过 isPublic 被错误地归类为全局可路由。注意：存在此问题的原因是对 CVE-2024-29415 的修复不完整。(CVE-2025-59436)

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

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

  - 已修复 Linux 内核中的下列漏洞：netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong `CIDR_POS(c)` for calculating array offsets, which can lead to integer underflow. As a result, it leads to slab out-of-bound access. This patch adds back the IP_SET_HASH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue. (CVE-2023-53179)

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

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

  - rtcmsc313修复 msc313_rtc_probe() 中的函数原型不匹配。利用 clang 内核控制流完整性kCFI、CONFIG_CFI_CLANG会针对预期函数指针原型验证间接调用目标以确保调用目标有效从而帮助缓解 ROP 攻击。如果它们不同，则运行时会出错，表现为内核错误或线程被终止。 msc313_rtc_probe() 直接传递 clk_disable_unprepare()该函数不具有 devm_add_action_or_reset() 的回调参数的匹配原型。重构以改用 devm_clk_get_enabled()。这是由于 Clang 的新 -Wcast-function-type-strict 标记比更简单的 -Wcast-function-type 仅检查类型宽度不匹配更敏感所导致。
    (CVE-2022-50322)

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

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

  - udf修复以 开头的文件名的某些路径名的未初始化的数组访问。和 的长度在 2 到 5 个字符之间因此 UDF 字符集转换代码将读取输出缓冲区中的未初始化内存。
    唯一的实际影响是当实际不需要时可能会在名称前面预加统一哈希但仍然建议修复此问题。 (CVE-2023-53165)

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

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

  - 已修复 Linux 内核中的下列漏洞：media: airspy: fix memory leak in airspy probe The commit ca9dc8d06ab6 (media: airspy: respect the DMA coherency rules) moves variable buf from stack to heap, however, it only frees buf in the error handling code, missing deallocation in the success path. Fix this by freeing buf in the success path since this variable does not have any references in other code. (CVE-2022-50326)

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

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

  - 已修复 Linux 内核中的下列漏洞：lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts Restore the SIMD usability check that was removed by commit 773426f4771b (crypto: arm/poly1305 - Add block-only interface). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. (CVE-2025-39802)

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

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

  - bpf修复因 fentry 附加失败而造成的内存泄漏如果附加 fentry 失败分配的 bpf trampoline 图像将保留在系统中。这可通过检查 /proc/kallsyms 进行验证。此内存泄露可通过简单的 bpf 程序验证如下所示 SEC(fentry/trap_init) int fentry_run() { return 0; }它将无法附加 trap_init因为此函数在内核初始化后被释放然后我们可以通过检查 /proc/kallsyms 发现 trampoline 图像留在系统中。 $ tail /proc/kallsyms ffffffffc0613000t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000t bpf_trampoline_6442453466_1 [bpf] $ bpftool btf 转储文件/sys/kernel/btf/vmlinux | $ tail /proc/kallsyms ffffffffc0613000t bpf_trampoline_6442453466_1 grep FUNC 'trap_init' [2522] FUNC 'trap_init' type_id=119 linkage=static $ echo $((6442453466 & 0x7fffffff)) 2522 请注意还存在两个 bpf trampoline 图像因为如果返回 -EINVAL则 libbpf 将回退到原始跟踪点。
    (CVE-2023-53221)

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

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

  - ttypcn_uart使用 debugfs_lookup() 修复内存泄漏调用 debugfs_lookup() 时结果必须调用 dput() 否则随着时间的推移将泄漏内存。要使事情更简单只需调用 debugfs_lookup_and_remove()其会同时处理所有逻辑。 (CVE-2023-53173)

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

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

  - regulatorcore修复处理 boot-on 时的 use_count 泄漏 我发现具有 boot-on 选项的 rdev 的电源调节器存在 use_count 泄漏。调节器_dev A调节器_dev B (boot-on) (boot-on) use_count=0 provides use_count=1 如果 rdev(A) 配置了“regulator-boot-on”则提供调节器(B) 的 use_count 将在 regulator_enable 内递增(rdev->supply)。因此B 将像 always-on 一样运行进一步平衡调节器启用/禁用实际上无法再将其禁用。
    然而 B 也配置了“regulator-boot-on”我们希望之后能够将其禁用。
    (CVE-2022-50250)

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

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

  - 已修复 Linux 内核中的下列漏洞：driver core: location: Free struct acpi_pld_info *pld before return false struct acpi_pld_info *pld should be freed before the return of allocation failure, to prevent memory leak, add the ACPI_FREE() to fix it. (CVE-2023-53211)

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

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

  - netopenvswitch修复端口输出上的争用假设在单机上进行以下设置 1. 具有一个桥接和默认流的 openvswitch 实例 2. 两个网络命名空间服务器和客户端 3.
    网桥上的两个 ovs 接口服务器和客户端 4. 为每个 ovs 接口准备一个 veth 对，并包含匹配的名称和 32 个 rx 和 tx 队列 5. 将 veth 对的末端移动到相应的网络命名空间 6. 为每个 分配 IP 地址以命名空间结尾的 veth需要为相同的子网 7. 在服务器网络命名空间上启动某个 http 服务器 8. 测试客户端命名空间中的客户端在遵循主机下的操作时是否可以访问 http 服务器有机会的 cpu 卡在无限循环中的步骤1. 发送大量并行请求到 http 服务器大约 3000 curl 应能工作2. 并行删除网络命名空间不删除接口或停止服务器而只是终止命名空间）极低的机率这将导致以下内核 cpu 卡住消息。如果未发生此情况请重试。下面还有输出中提及的函数的 bpftrace 输出。此处发生的一系列事件为1. 会在进程中的某处调用“unregister_netdevice_many_notify”删除网络命名空间 2. 在 veth 的两端首先设置“NETREG_UNREGISTERING”然后运行“synchronize_net” 3. 然后调用“call_netdevice_notifiers” ` 4。此问题然后由调用“ovs_netdev_detach_dev”的“dp_device_event”进行处理如果找到 vport，即附加到 ovs 的 veth 接口的情况5。这会删除设备的 rx_handlers，但不阻止将程序包发送到设备 6. “dp_device_event”然后将 vport 删除排入队列以便在后台工作，因为我们没有在取消注册路径中保留需要的 ovs_lock 7. “unregister_netdevice_many_notify”继续调用设置“netdev_unregister_kobject”的“netdev_unregister_kobject”将 real_num_tx_queues 设置为 0 8. 端口删除会继续但详细信息与此问题无关9. 在未来的某个时候后台任务会删除 7. 之后 9. 之前的 vport If。一个数据包被发送到 ovs vport在这个时间点未被删除即使设备正在取消注册ovs vport也会将其转发到 `dev_queue_xmit` 流。在 `skb_tx_hash`在 `dev_queue_xmit` 路径中调用存在一个 while 循环如果数据包记录了 rx_queue当 `dev->real_num_tx_queues` 为零时该循环是无限的。为防止发生这种情况我们更新了“do_output”以按照与未找到设备相同的方式处理没有运营商的设备这将是 9. 完成之后的代码路径。此外，如果我们现在遇到无限循环，我们现在会在“skb_tx_hash”中生成警告。 bpftrace第一个单词是函数名称
    __dev_queue_xmit serverreal_num_tx_queues1，cpu:2，pid:28024，tid:28024，skb_addr:
    0xffff9edb6f207000reg_state: 1 netdev_core_pick_tx serveraddr: 0xffff9f0a46d4a000 real_num_tx_queues
    1, cpu2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1 dp_device_event server
    real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1 Synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 synchronize_rcu_expedited, cpu 9pid 9 21024、tid21024 synchronize_rcu_expeditedcpu 9、pid21024、tid21024 dp_device_event serverreal_num_tx_queues: 1 cpu 9、pid:21024、tid21024、event 6、reg_state:2 ovs_netdev_detach_dev server:1, pid21024、tid21024、reg_state
    2 netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024 netdev_rx_handler_unregister ret server
    real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2 dp_ ---truncated--- (CVE-2023-53188)

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

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

  - xfrm在 xfrm_update_ae_params 中添加了。但是xfrm_new_ae(...) 的当前实现允许恶意用户直接取消引用空指针并造成内核崩溃如下所示。BUG：
    内核空指针取消引用地址0000000000000000 PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0 Oops
    0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8 硬件名称QEMU Standard PC (i440FX + PIIX,1996)BIOS 相关1.16.0-0-gd239552ce722-prebuilt.qemu.o4RIP0010:memcpy_orig+0xad/0x140 代码e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 310 4c 72 06 4c 8b 4e 08 c RSP0018:ffff888008f57658 EFLAGS00000202 RAX: 0000000000000000 RBX
    ffff888008bd0000 RCX: ffffffff8238e571 RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
     R120000000000000000  : ffff888008f57818 R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 调用跟踪 <TASK> ? __die+0x1f/0x70 ? page_fault_oops+0x1e8/0x500 ? __pfx_is_prefetch.constprop.0+0x10/0x10?
    __pfx_page_fault_oops+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? fixup_exception+0x36/0x460 ?
    _raw_spin_unlock_irqrestore+0x11/0x40 ? exc_page_fault+0x5e/0xc0 ? asm_exc_page_fault+0x26/0x30 xfrm_update_ae_params+0xd1/0x260 ? memcpy_orig+0xad/0x140 ? __pfx__raw_spin_lock_bh+0x10/0x10 xfrm_update_ae_params+0xe7/0x260 xfrm_new_ae+0x298/0x4e0 ? __pfx_xfrm_new_ae+0x10/0x10 ?
    __pfx_xfrm_new_ae+0x10/0x10 xfrm_user_rcv_msg+0x25a/0x410 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ?
    __alloc_skb+0xcf/0x210 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1c/0x70 ?
    __stack_depot_save+0x39/0x4e0 ? __kasan_slab_free+0x10a/0x190 ? kmem_cache_free+0x9c/0x340 ? netlink_recvmsg+0x23c/0x660 ? sock_recvmsg+0xeb/0xf0 ? __sys_recvfrom+0x13c/0x1f0 ?
    __x64_sys_recvfrom+0x71/0x90 ? do_syscall_64+0x3f/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc ? copyout+0x3e/0x50 netlink_rcv_skb+0xd6/0x210 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ?
    __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_sock_has_perm+0x10/0x10 ? mutex_lock+0x8d/0xe0 ?
    __pfx_mutex_lock+0x10/0x10 xfrm_netlink_rcv+0x44/0x50 netlink_unicast+0x36f/0x4c0 ?
    __pfx_netlink_unicast+0x10/0x10 ? netlink_recvmsg+0x500/0x660 netlink_sendmsg+0x3b7/0x700 已为此 Null-ptr-deref 缺陷 分配 CVE-2023-3772。并且此提交在 xfrm_update_ae_params 中添加了其他空检查以修复 NPD。 (CVE-2023-53147)

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

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

  - 已修复 Linux 内核中的下列漏洞：perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox() pci_get_device() will increase the reference count for the returned 'dev'. We need to call pci_dev_put() to decrease the reference count. Since 'dev' is only used in pci_read_config_dword(), let's add pci_dev_put() right after it. (CVE-2022-50318)

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

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

  - 已修复 Linux 内核中的下列漏洞：KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired ratio doesn't match the current ratio, not if the ratio L1 is using for L2 diverges from the default.
    Functionally, the end result is the same as KVM will run L2 with L1's multiplier if L2's multiplier is the default, i.e. checking that L1's multiplier is loaded is equivalent to checking if L2 has a non-default multiplier. However, the assertion that TSC scaling is exposed to L1 is flawed, as userspace can trigger the WARN at will by writing the MSR and then updating guest CPUID to hide the feature (modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking KVM's state_test selftest to do vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR); after restoring state in a new VM+vCPU yields an endless supply of: ------------[ cut here ]------------ WARNING: CPU: 10 PID:
    206939 at arch/x86/kvm/svm/nested.c:1105 nested_svm_vmexit+0x6af/0x720 [kvm_amd] Call Trace:
    nested_svm_exit_handled+0x102/0x1f0 [kvm_amd] svm_handle_exit+0xb9/0x180 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] ? trace_hardirqs_off+0x4d/0xa0 __se_sys_ioctl+0x7a/0xc0 __x64_sys_ioctl+0x21/0x30 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Unlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check into the if-statement is wrong as KVM needs to ensure L1's multiplier is loaded in the above scenario. Alternatively, the WARN_ON() could simply be deleted, but that would make KVM's behavior even more subtle, e.g. it's not immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when checking only tsc_ratio_msr. (CVE-2023-53208)

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

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

  - md/raid10刷新写入时防止软锁定 目前对 raid1/raid10 插入的 bio 没有限制。刷新写入时raid1 有 cond_resched()而 raid10 则没有太多写入可导致软锁定。可通过对具有 ramdisks 的 raid10 的回写测试轻松触发后续软锁定
    watchdog缺陷软锁定 - CPU#10 卡住 27 秒[md0_raid10:1293] 调用跟踪 <TASK> call_rcu+0x16/0x20 put_object+0x41/0x80 __delete_object+0x50/0x90 delete_object_full+0x2b/0x40 kmemleak_free+0x46/0xa0 slab_free_freelist_hook.constprop.0+0xpooled/0x1a0 mem_cached0m03x_free+mem_cached0m03x_free +0x1f/0x30 mempool_free+0x3a/0x100 bio_free+0x59/0x80 bio_put+0xcf/0x2c0 free_r10bio+0xbf/0xf0 raid_end_bio_io+0x78/0xb0 one_write_done+0x8a/0xa0 raid10_end_write_request+0x1b4/0x430 bio_endio+0x175/0x320 brd_submit_bio+0x3b9/0x9b7 [ brd] __submit_bio+0x69/0xe0 submit_bio_noacct_nocheck+0x1e6/0x5a0 submit_bio_noacct+0x38c/0x7e0 flush_pending_writes+0xf0/0x240 raid10d+0xac/0x1ed0 通过像 raid1 一样向 raid10 添加 cond_resched() 来修复 问题。请注意无限插入的 bio 仍需要优化例如在大量脏页回写的情况下这将占用大量内存io 会在插入中花费很长时间因此 io 延迟很差。
    (CVE-2023-53151)

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

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

  - usbdwc3针对设备端点命令超时删除 WARN_ON 此提交解决了一个罕见的端点命令超时此问题在启用“panic_on_warn”时由于警告而导致内核错误以及在禁用“panic_on_warn”时打印不必要的调用跟踪。在软件控制的快速连接/断开连接测试案例中会出现此问题。以下是我们观察到的一个此类端点命令超时1.
    连接 ======= ->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup
    ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data
    ->dwc3_send_gadget_ep_cmd 2. 断开连接 ========== ->dwc3_thread_interrupt
    ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data
    ->dwc3_send_gadget_ep_cmd 在问题场景中在 Exynos 平台中我们发现之前连接的控制权传输尚未完成尚未发送结束传输命令作为断开序列的一部分以及处理 USB_ENDPOINT_HALT 功能请求超时。这可能是预期的情况因为控制器正在处理作为之前连接的一部分发送的 EP 命令。可能最好在发送设备端点命令的所有位置中删除 WARN_ON以避免由于 warn 导致的不必要的内核错误。 (CVE-2025-39801)

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

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

  - ipc修复 init_mqueue_fs() 中的 setup_mq_sysctls() 失败时mqueue_inode_cachep 不会释放。为了修复此问题已对发布路径重新排序。
    (CVE-2022-50284)

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

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

  - scsiufscore从 ufshcd_uic_cmd_compl() 删除 WARN_ON_ONCE() 调用处理 UIC 命令时UIC 完成中断可能被禁用。重新启用 UIC 完成中断时会触发 UIC 中断并命中 WARN_ON_ONCE(!cmd) 语句。因此此修补程序删除了此内核警告。 (CVE-2025-39803)

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

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

  - vxlan修复 nexthop 哈希大小 nexthop 代码预期为 31 位哈希例如 fib_multipath_hash() 和 rt6_multipath_hash() 返回的哈希。传递由 skb_get_hash() 返回的 32 位哈希可导致发生与设置了 MSB 时“int hash”为负数有关的问题。如果是哈希阈值 nexthop 组nexthop_select_path_hthr() 将不成比例地选择第一个 nexthop 组条目。对于可恢复的 nexthop 群组nexthop_select_path_res() 可能在 nh_buckets[]中执行越界访问例如导致以下错误的 hash = -912054133 num_nh_buckets = 2 bucket_index = 65535 addressffffc900025910c8 PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 856 Comm: kworker/4:3 未受感染 6.5.0-rc2+ #34 硬件名称: QEMU Standard PC ( i440FX + PIIX，1996，BIOS 1.16.2-debian-1.16.2-1 04/01/2014 工作队列ipv6_addrconf addrconf_dad_work RIP
    0010:nexthop_select_path+0x197/0xbf0 代码 c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d e8 13 13 13 19 19 0010 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85 RSP0018:ffff88810c36f260 EFLAGS00010246 RAX: 0000000000000000 RBX
    00000000002000c0 RCX: ffffffffaf02dd77 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8 RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219 R10: ffffc900025910cf R11:
     R1231392d2068736168  : 00000000002000c0 R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900 FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900025910c8 CR3: 0000000129d00000 CR40000000000750ee0 PKRU55555554 调用跟踪 <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ?
    __pfx_is_prefetch.constprop.0+0x10/0x10? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 nexthop_select_path+0x197/0xbf0 nexthop_select_path+0x197/0xbf0 lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10
    __pfx___lock_acquire+0x10/0x10 ? __pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350
    __dev_queue_xmit+0x513/0x1e20 ? __pfx___dev_queue_xmit+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ?
    __pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ?
    __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ?
    __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ?
    __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 __kthread_arkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ---truncated--- (CVE-2023-53192)

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

ID	名称	严重性
265168	Linux Distros 未修补的漏洞：CVE-2023-53287	medium
265167	Linux Distros 未修补的漏洞：CVE-2022-50324	medium
265166	Linux Distros 未修补的漏洞：CVE-2023-53217	high
265165	Linux Distros 未修补的漏洞：CVE-2023-53255	medium
265164	Linux Distros 未修补的漏洞：CVE-2022-50240	high
265163	Linux Distros 未修补的漏洞：CVE-2022-50243	high
265162	Linux Distros 未修补的漏洞：CVE-2023-53265	high
265161	Linux Distros 未修补的漏洞：CVE-2022-50234	high
265160	Linux Distros 未修补的漏洞：CVE-2025-39828	high
265159	Linux Distros 未修补的漏洞：CVE-2022-50264	medium
265158	Linux Distros 未修补的漏洞：CVE-2023-53331	high
265157	Linux Distros 未修补的漏洞：CVE-2023-53277	medium
265156	Linux Distros 未修补的漏洞：CVE-2025-39822	medium
265155	Linux Distros 未修补的漏洞：CVE-2023-53267	medium
265153	Linux Distros 未修补的漏洞：CVE-2025-39818	high
265152	Linux Distros 未修补的漏洞：CVE-2023-53206	medium
265151	Linux Distros 未修补的漏洞：CVE-2023-53288	medium
265150	Linux Distros 未修补的漏洞：CVE-2022-50254	medium
265149	Linux Distros 未修补的漏洞：CVE-2025-10527	high
265148	Linux Distros 未修补的漏洞：CVE-2025-10533	high
265147	Linux Distros 未修补的漏洞：CVE-2023-53241	medium
265146	Linux Distros 未修补的漏洞：CVE-2022-50280	medium
265145	Linux Distros 未修补的漏洞：CVE-2023-53333	high
265144	Linux Distros 未修补的漏洞：CVE-2023-53299	medium
265143	Linux Distros 未修补的漏洞：CVE-2022-50257	medium
265142	Linux Distros 未修补的漏洞：CVE-2025-39829	medium
265141	Linux Distros 未修补的漏洞：CVE-2022-50313	medium
265139	Linux Distros 未修补的漏洞：CVE-2022-50287	medium
265138	Linux Distros 未修补的漏洞：CVE-2022-50268	medium
265137	Linux Distros 未修补的漏洞：CVE-2022-50323	medium
265136	Linux Distros 未修补的漏洞：CVE-2025-59437	low
265135	Linux Distros 未修补的漏洞：CVE-2025-59436	low
265134	Linux Distros 未修补的漏洞：CVE-2023-53179	high
265054	Linux Distros 未修补的漏洞：CVE-2022-50322	medium
265053	Linux Distros 未修补的漏洞：CVE-2023-53165	medium
265052	Linux Distros 未修补的漏洞：CVE-2022-50326	medium
265051	Linux Distros 未修补的漏洞：CVE-2025-39802	high
265050	Linux Distros 未修补的漏洞：CVE-2023-53221	medium
265049	Linux Distros 未修补的漏洞：CVE-2023-53173	medium
265048	Linux Distros 未修补的漏洞：CVE-2022-50250	medium
265047	Linux Distros 未修补的漏洞：CVE-2023-53211	medium
265046	Linux Distros 未修补的漏洞：CVE-2023-53188	medium
265045	Linux Distros 未修补的漏洞：CVE-2023-53147	medium
265044	Linux Distros 未修补的漏洞：CVE-2022-50318	medium
265043	Linux Distros 未修补的漏洞：CVE-2023-53208	medium
265042	Linux Distros 未修补的漏洞：CVE-2023-53151	medium
265041	Linux Distros 未修补的漏洞：CVE-2025-39801	medium
265040	Linux Distros 未修补的漏洞：CVE-2022-50284	medium
265038	Linux Distros 未修补的漏洞：CVE-2025-39803	high
265037	Linux Distros 未修补的漏洞：CVE-2023-53192	high

检测

Nessus 的 Misc. 系列

medium

medium

high

medium

high

high

high

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

high

high

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

low

low

high

medium

medium

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

high

high