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

  - 在某些情况下“named”可能会在处理包含 TKEY 记录的正确签名查询时崩溃。仅当传入请求具有来自“named”配置中声明的密钥的有效事务签名 (TSIG)时才能访问受影响的代码。此问题会影响 BIND 9 版本 9.20.0 至 9.20.20、 9.21.0 至 9.21.19以及 9.20.9-S1 至 9.20.20-S1。BIND 9 版本 9.18.0 至 9.18.46 以及 9.18.11-S1 至 9.18.46-S1 不受影响。 (CVE-2026-3119)

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

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

  - mptcppm在内核中始终将 signal+subflow endp 标记为已使用 Syzkaller 设法找到可生成此警告的操作组合msk->pm.local_addr_used == 0 警告net/mptcp/pm_kernel.c 1071 at __mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline] CPU#1syz.2.17/961 警告
    net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline] CPU#1syz.2.17/961 警告net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net /mptcp/pm_kernel.c:1210, CPU#1在以下链接中链接的 syz.2.17/961 模块CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full)硬件名称QEMU Ubuntu 25.10 PC v2i440FX + PIIX+ 10.1 计算机1996BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP
    0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inline] RIP
    0010:mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1103 [inline] RIP
    0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210 代码89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 40 db df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP0018:ffffc90001663880 EFLAGS00010293 RAX
    ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10:
     R11ffffffff82de18ba  : 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: <TASK> genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink. c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [内联] netlink_unicast+0x3e9/0x4c0 net /netlink/af_netlink.c:1344 netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:742____sys_sendmsg+0x272/0x3b0 net/socket.c:2592 ___sys_sendmsg+0x2de/0x320 net/socket.c:2646 __sys_sendmsg net/socket.c 2678 [内联]
    __do_sys_sendmsg net/socket.c:2683 [内联] __se_sys_sendmsg net/socket.c:2681 [内联]
    __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [内联] do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP:
    0033:0x7f66346f826d 代码ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 04c <48> 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX
    00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 </TASK> 导致 的操作似乎为 - 将 MPTCP 子流限制设置为 0 - 使用“TCP signal端点”创建一个 TCP 子流限制为 0 - 将 MPTCP 子流限制设置为 0 ' flags - 从不同的地址创建新 MPTCP 连接将发送链接到 MPTCP 端点的 ADD_ADDR'signal' 标记但不初始化任何子流'subflow' 标记 - 删除 MPTCP 端点 ---truncated---CVE-2026-23321

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

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

  - cpufreqintel_pstate修复 turbo 禁用期间发生的崩溃当使用内核命令行参数 nosmt 或 maxcpus 引导系统以限制 CPU 数量时禁用 turbo通过echo 1 > /sys/devices/system/cpu/intel_pstate/no_turboresults崩溃中PF: 在内核模式 PF 中存在主管读取访问: error_code(0x0000) - not-present 页面 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI ... RIP
    0010:store_no_turbo+0x100/0x1f0 ... 出现这种情况的原因是即使 CPU 未在线for_each_possible_cpu() 也会返回 CPU。对于这些 CPU all_cpu_data[] 将为 NULL。自提交 973207ae3d7c (cpufreq
    intel_pstate重新安排最大频率更新处理代码即使未在线的 CPU 也会取消引用 all_cpu_data[] 造成空指针取消引用。要修复此问题请将 CPU 编号传递至 intel_pstate_update_max_freq() 并为具有有效 cpufreq 策略的 CPU 使用 all_cpu_data[] 。 (CVE-2026-23332)

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

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

  - sched/deadline修复 PI de-boosting 期间缺少的 ENQUEUE_REPLENISH 在大型计算机的 RT 内核上运行 stress-ng --schedpolicy 0 可能导致以下警告已编辑。 schedDL 提升任务 PID 22725缺少 REPLENISH 标记警告CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ...running_bw 下溢调用跟踪dequeue_task_dl+0x15c/ 0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228
    __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ... 该问题是当通过 sched_setscheduler() 将 SCHED_DEADLINE 任务锁定持有者更改为较低优先级时它可能无法正确继承潜在 DEADLINE 提供者的参数如果它在过去较短的期限内未继承这些参数而非当时的供体。这可能导致带宽核算损坏因为 enqueue_task_dl() 不会将锁定持有者识别为已提升。在以下情况下出现此场景： 1. DEADLINE 任务（供给者）在另一个 DEADLINE 任务（持有者）持有的 PI 互斥体上阻断，但持有者未继承参数（例如，其已有更短的期限）。 2. sched_setscheduler()将持有者从 DEADLINE 更改为较低类同时仍然持有互斥体 3。持有者现在应继承提供者的 DEADLINE 参数并使用 ENQUEUE_REPLENISH 排队但不会发生这种情况通过引入 __setscheduler_dl_pi() 修复此问题该函数会在何时检测DEADLINE正常任务或升级任务被设置为降低的优先级类别。万一该函数使任务继承提供者 (pi_se) 的 DEADLINE 参数并设置 ENQUEUE_REPLENISH 标记以确保在下一个入列操作期间正确计算带宽。 (CVE-2026-23371)

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

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

  - netipv6修复了 IPv4 路由引用环回 IPv6 nexthop 时的错误使用环回设备创建独立 IPv6 nexthop 对象时例如 ip -6 nexthop add id 100 dev lofib6_nh_init() 会将其错误分类为拒绝路由。这是因为 nexthop 对象没有目标前缀 (fc_dst=::)从而导致 fib6_is_reject() 匹配任何环回 nexthop。拒绝路径会跳过 fib_nh_common_init()从而使 nhc_pcpu_rth_output 处于未分配状态。如果 IPv4 路由之后引用此 nexthop__mkroute_output() 会取消引用空 nhc_pcpu_rth_output 和错误。简化 fib6_nh_init() 中的检查仅匹配显式拒绝路由 (RTF_REJECT) 而不是使用 fib6_is_reject()。fib6_is_reject() 中的环回升级启发式由 ip6_route_info_create_nh() 单独处理。
    进行此更改后这三种情况的行为如下1. 明确拒绝路由ip -6 route addable unreachable 2001:db8::/64设置 RTF_REJECT输入拒绝路径跳过 fib_nh_common_init()。无行为变更。 2. 隐式环回拒绝路由 (ip -6 route add 2001:db8::/32 dev lo)未设置 RTF_REJECT、采用正常路径、调用 fib_nh_common_init()。 ip6_route_info_create_nh() 之后仍会将其升级为拒绝。已分配 nhc_pcpu_rth_output 但未使用此问题无害。 3. 独立的 nexthop 对象 (ip -6 nexthop add id 100 dev lo)未设置 RTF_REJECT、采用正常路径、调用 fib_nh_common_init()。 nhc_pcpu_rth_output 已正确分配修复了当 IPv4 路由引用此 nexthop 时发生的崩溃。 (CVE-2026-23300)

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

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

  - scsitarget修复 __configfs_open_file() 中的递归锁定 在 flush_write_buffer 中获取 &p->frag_sem然后调用加载的存储函数此处为 target_core_item_dbroot_store()。
    此函数调用了 filp_open()根据调用跟踪此函数之后又调用了这些函数以相反顺序按照调用跟踪 down_read __configfs_open_file do_dentry_open vfs_open do_open path_openat do_filp_open file_open_name filp_open target_core_item_dbroot_store flush_write_buffer configfs_write_iter target_core_item_dbroot_store() 通过尝试更改文件路径来尝试验证新文件路径。打开提供的文件路径；但是在这种情况下缺陷报告会显示 db_rootnot a directory
    /sys/kernel/config/target/dbroot 表示已尝试打开当前正在处理的相同 configfs 文件。因此它正在尝试获取其已保留在 flush_write_buffer() 中获得的信号量的同一文件的 frag_sem 信号量从而导致以嵌套方式获取信号量并可能出现递归锁定。修复方法是修改 target_core_item_dbroot_store() 以使用 kern_path() 而不是 filp_open() 以避免使用文件系统特定的函数 __configfs_open_file() 打开文件并进一步修改它以使其与此补丁兼容。
    (CVE-2026-23292)

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

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

  - ALSAusb-audio对 UAC3 标头验证使用正确的版本 UAC3 AC 标头描述符的验证器表中的条目是使用错误的协议版本 UAC_VERSION_2 进行定义而应为 UAC_VERSION_3。这会导致验证器永不匹配实际的 UAC3 设备 (protocol == UAC_VERSION_3)从而造成其标头描述符完全绕过验证。呈现截断的 UAC3 标头的恶意 USB 设备可利用此漏洞在驱动程序稍后访问未经验证的描述符字段时造成越界读取。在与最近修复的 UAC3 功能单元子类型拼写错误相同的提交中引入此缺陷似乎是因为从 UAC2 部分创建 UAC3 部分时发生相同的复制粘贴错误所致。 (CVE-2026-23318)

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

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

  - 通过特别构建的域即可造成 BIND 解析器中发生内存泄漏只需查询此域即可。此问题会影响 BIND 9 版本 9.20.0 至 9.20.20、 9.21.0 至 9.21.19以及 9.20.9-S1 至 9.20.20-S1。BIND 9 版本 9.18.0 至 9.18.46 以及 9.18.11-S1 至 9.18.46-S1 不受影响。 (CVE-2026-3104)

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

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

  - 处理以 SIG(0) 签名的 DNS 查询时“named”服务器中存在一个返回后使用漏洞。攻击者可使用特制的 DNS 请求造成 ACL 不当匹配 IP 地址。在默认允许的 ACL仅拒绝特定 IP 地址中这可能会导致未经授权的访问。Default-deny ACL 应进行故障保护。此问题会影响 BIND 9 版本 9.20.0 至 9.20.20、 9.21.0 至 9.21.19以及 9.20.9-S1 至 9.20.20-S1。BIND 9 版本 9.18.0 至 9.18.46 以及 9.18.11-S1 至 9.18.46-S1 不受影响。 (CVE-2026-3591)

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

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

  - pinctrlbalance平衡修复加载时的警告跟踪 回调函数“eqbr_irq_mask_ack()”中也会调用回调函数“eqbr_irq_mask()”和“eqbr_irq_ack()”。这样做是为了避免源代码重复。问题是 在函数“eqbr_irq_mask()”中还调用了 gpiolib 函数“gpiochip_disable_irq()”。这会在日志中为加载时的每个 gpio 生成以下警告跟踪。 [ 6.088111] ------------[ 在此处切换 ]------------ [ 6.092440] WARNINGCPU3PID1位于 drivers/gpio/gpiolib .c:3810 gpiochip_disable_irq+0x39/0x50 [ 6.097847] 中链接的模块 [ 6.097847] CPU
    3 UID0 PID1 Comm:swapper/0 受感染GW 6.12.59+ #0 [ 6.097847] 受感染[W]=WARN [ 6.097847] RIP
    0010:gpiochip_disable_irq+0x39/0x50 [ 6.097847] Code39 c6 48 19 c0 21 c6 48 c1 e6 05 48 03 b2 38 03 00 00 48 81 fe 00 f0 ff ff 77 11 48 8b 46 08 f6 c4 02 f074 06 80 66 09 fb c3 <0f> 0b 90 0f 1f 40 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 [ 6.097847] RSP: 0000:ffffc9000000b830 EFLAGS: 00010046 [ 6.097847] RAX: 0000000000000045 RBX: ffff888001be02a0 RCX: 0000000000000008 [ 6.097847] RDX: ffff888001be9000 RSI
    ffff888001b2dd00 RDIffff888001be02a0 [ 6.097847] RBP: ffffc9000000b860 R080000000000000000 R09
    0000000000000000 [ 6.097847] R10: 0000000000000001 R11: ffff888001b2a154 R12: ffff888001be0514 [ 6.097847] R13: ffff888001be02a0 R14: 0000000000000008 R15: 0000000000000000 [ 6.097847] FS: 0000000000000000(0000) GS:ffff888041d80000(0000) knlGS :0000000000000000 [ 6.097847] CS: 0010 DS: 0000 ES: 0000 CR0
    0000000080050033 [ 6.097847] CR2: 0000000000000000 CR3: 0000000003030000 CR4: 00000000001026b0 [ 6.097847] 调用跟踪 [ 6.097847] <TASK> [ 6.097847] ? eqbr_irq_mask+0x63/0x70 [ 6.097847] no_action+0x10/0x10 [6.097847] eqbr_irq_mask_ack+0x11/0x60 在其他驱动程序 (drivers/pinctrl/starthree/pinctrl-starIVE-jh7100.c) 中中断未在此处禁用。要修复此问题请勿调用“eqbr_irq_mask()”和“eqbr_irq_ack()”函数。改为直接实现 而不禁用中断。
    (CVE-2026-23308)

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

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

  - canusbf81604正确处理短中断 urb 消息如果收到长度不正确的中断 urb 请正确检测该数据并且不尝试将数据视为有效数据。 (CVE-2026-23334)

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

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

  - nfcnci释放 nci_transceive 上错误路径上的 skbnci_transceive() 取得调用程序传递的 skb 的所有权但 -EPROTO、-EINVAL 和 -EBUSY 错误路径会在未释放其的情况下返回。由于清除后续变更修复的 NCI_DATA_EXCHANGE 的问题nci/nci_dev selftest 在 NIPA 中偶尔会命中错误路径kmemleak 检测到泄漏未引用对象 0xff11000015ce6a40大小 640comm nci_dev、pid 3954、jiffies 4295441246 十六进制转储前 32 字节6b 6b 6b 6b 00 a4 00 0c 02 e1 03 6b 6b 6b 6b 6b kkkk.......kkkkk 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkknode_profallocembacktrace (crc 7c40cc2a): +0x492/0x630 __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xc6/0x8f0 sock_alloc_send_pskb+0x326/0x3f0 nfc_alloc_send_skb+0x94/0x1d0 rawsock_sendmsg+0x162/0x4c0 do_syscall_64+CVE-2026-23339( 0xfc0)

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

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

  - x86/efi延迟启动服务内存的释放 efi_free_boot_services() 使用 memblock_free_late() 释放被 EFI_BOOT_SERVICES_CODE 和 EFI_BOOT_SERVICES_DATA 占用的内存。其中存在两个问题memblock_free_late() 应用于通过 memblock_alloc() 分配的内存而通过 memblock_reserve() 预留的内存应通过 free_reserved_area() 释放。更严重的是当 CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boot_services() 在内存映射的延迟初始化完成之前被调用。Benjamin Herrenschmidt 报告这会在只有 512MB RAM 的 EC2 t3a.nano 实例上造成约 140MB 的 RAM 泄漏。如果已释放的内存驻留在内存映射仍未初始化的区域中则不会实际释放这些内存因为 memblock_free_late() 会调用 memblock_free_pages()而后者会跳过未初始化的页面。此时使用 free_reserved_area() 也有问题因为 __free_page() 会访问已释放页面的伙伴并且可能再次位于内存映射的未初始化部分。延迟整个 efi_free_boot_services() 可能会产生问题因为除了释放启动服务内存它还会在没有任何同步的情况下更新 efi.memmap这是在启动后期出现并发时所不希望发生的情况。更可靠的方法是仅延迟 EFI 引导服务内存的释放。将 efi_free_boot_services() 拆分为两部分。首先 efi_unmap_boot_services() 将应释放的范围收集到数组中然后在延迟的 init 完成时efi_free_boot_services() 释放它们。 (CVE-2026-23352)

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

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

  - xdp当计算的 tailroom 为负时生成警告 许多以太网驱动程序报告 xdp Rx 队列碎片大小与 DMA 写入大小相同。但是，此字段的唯一用户，即 bpf_xdp_frags_increase_tail()，明确地预期为 truesize。此类差异在某些情况下会导致非特定内存损坏问题例如在 ixgbevf 中DMA 写入大小上限为 3 KB因此当运行 xskxceiver 的 XDP_ADJUST_TAIL_GROW_MULTI_BUFF 时6K 数据包完全使用 2 个缓冲区中的所有 DMA 可写入空间。如果仅 rxq->frag_size 正确设置为 4K这样做没有问题但 3K 的值会导致负的 tailroom因为存在非零页面偏移。在这种情况下我们本应返回 -EINVAL 并对其进行处理但由于 tailroom 被存储为未签名的 int因此报告其位于 UINT_MAX 附近的某处导致 tail 增大即使请求的偏移过大大（上述测试中为 2K 左右）。这稍后会导致各种不明的调用跟踪。 7340.337579[  ] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6 [ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4 [ 7340.338179] in libc.so.6[61c9d,7f4161aaf000 +160000] [ 7340.339230] in xskxceiver[42b5,400000+69000] 中的 [ 7340.340300] 可能位于 CPU 6核心 0、套接字 6 [ 7340.340302] 代码ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f09 ff ff 85 ec fe [ 7340.340888] 可能在 CPU 3核心 0套接字 3上 [ 7340.345088] 代码
    00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7 [ 7340.404334] Oops一般保护错误可能针对非规范地址 0x6d255010bdffc: 0000 [#1] SMP NOPTI [7340.405972] CPU: 7 UID: 0 PID1439 Commxskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy) [7340.408006] 硬件名称QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/ 2014 [7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80 [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS
    00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7340.420286] CR2: 00007f415bffffd58 CR3:
    0000000103f03002 CR4: 0000000000772ef0 [ 7340.421237] PKRU: 55555554 [ 7340.421623] 调用跟踪 [7340.421987] <TASK> [ 7340.422309] ? softleaf_from_pte+0x77/0xa0 [ 7340.422855] swap_pte_batch+0xa7/0x290 [ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zap_pte_range+0x281/0x580 [ 7340.424607] zap_pmd_range.isra.0+ 0xc9/0x240 [ 7340.425177] unmap_page_range+0x24d/0x420 [ 7340.425714] unmap_vmas+0xa1/0x180 [ 7340.426185] exit_mmap+0xe1/0x3b0 [ 7340.426644] __mmput+0x41/0x150 [ 7340.427098] exit_mm+0xb1/0x110 [ 7340.427539] do_exit+0x1b2/0x460 [ 7340.427992] do_group_exit+0x2d/0xc0 [7340.428477] get_signal+0x79d/0x7e0 [ 7340.428957] arch_do_signal_or_restart+0x34/0x100 [ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0 [ 7340.430159] do_syscall_64 / ---truncated--- (CVE-2026-23343)

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

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

  - wifimac80211修复 Mesh_rx_csa_frame() 中的空指针取消引用在 Mesh_rx_csa_frame() 中在未事先进行空检查的情况下在第 1638 和 1642 行取消引用 elems->mesh_chansw_params_ie
    ifmsh->chsw_ttl = elems->mesh_chansw_params_ie->mesh_ttl; ... pre_value = le16_to_cpu(elems->mesh_chansw_params_ie->mesh_pre_value);上述 Mesh_matches_local() 检查仅验证 Mesh ID、Mesh Configuration 和 Supported Rates IE。它不会验证是否存在 Mesh Channel Switch Parameters IE（元素 ID 118）。当已接收的 CSA 操作框架忽略该 IE 时ieee802_11_parse_elems() 将 elems->mesh_chansw_params_ie 保留为空且无条件取消引用造成内核空指针取消引用。已建立对等链路 (PLINK_ESTAB) 的远程 Mesh 对等机可通过发送构建的 SPECTRUM_MGMT/CHL_SWITCH 操作帧来触发此问题该帧包含匹配的 Mesh ID 和 Mesh Configuration IE 但忽略了 Mesh 通道切换参数 IE。除了默认的开放式网状网络对等互联之外无需任何身份验证。在内核 6.17.0-5-generic 中已确认通过 mac80211_hwsim 会发生崩溃BUG
    kernel 空指针取消引用地址0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP
    0010ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000 通过在 Mesh_matches_local() 返回后为 Mesh_chansw_params_ie 添加 NULL 检查来修复此问题与在整个 Mesh 代码中保护其他可选 IE 的方式一致。此缺陷自 v3.13 2014 年 1 月 19 日发布以来一直存在。
    (CVE-2026-23279)

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

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

  - net: usb: pegasus验证 USB 端点 在绑定之前pegasus 驱动程序应验证其正在探测的设备是否具有正确数量和类型的 USB 端点。如果恶意设备没有相同的 urb该驱动程序稍后会在其盲目访问这些端点时崩溃。 (CVE-2026-23290)

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

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

  - smb客户端修复由于 smb2_unlink() 中未初始化的 var 所导致的 oops 如果 SMB2_open_init() 或 SMB2_close_init() 失败例如重新连接iovs 集 @rqst 将保持未初始化状态从而调用 SMB2_open_free()、SMB2_close_free() 或 smb2_set_related它们上的 () 将发生 oops。在 @rqst 中设置 @close_iov 和 @open_iov 之前通过初始化 @close_iov 和 @open_iov 来修复此问题。 (CVE-2026-23282)

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

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

  - arm64io提取 ioremap_prot() 中的用户内存类型 在通用 ioremap() 实现之外 ioremap_prot() 的唯一调用程序是 generic_access_phys()它传递从目标“pfn”的用户映射确定的“pgprot_t”值' 正被内核访问。在 arm64 中“pgprot_t”包含来自 pte 的所有非地址位包括权限控制因此我们最终从 ioremap_prot() 返回新的用户映射因此在从系统上的内核访问时会发生错误 PAN |无法处理来自虚拟地址 ffff80008ea89000 | 中不可读内存的内核读取。 ...调用跟踪
    | __memcpy_fromio+0x80/0xf8 | | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | | access_remote_vm+0x18/0x30 | | environ_read+0x238/0x3e8 | | vfs_read+0xe4/0x2b0 | | ksys_read+0xcc/0x178 |
    __arm64_sys_read+0x4c/0x68 仅从 ioremap_prot() 中的用户“pgprot_t”提取内存类型并断言正在向我们传递用户映射以保护我们免受未来可能需要额外处理的任何更改的影响。为避免错误标记 ioremap() 的用户请提供我们自己的 ioremap() 宏以封装 __ioremap_prot()。 (CVE-2026-23346)

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

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

  - bpf修复 bpf_trampoline_link_cgroup_shim 中的一个 UAF 问题 此缺陷的根本原因是当“bpf_link_put”将“shim_link->link.link”的 refcount 减少为零时资源被视为已释放但可能仍会通过“tr- “cgroup_shim_find”中的 >progs_hlist。“bpf_shim_tramp_link_release”中“tr->progs_hlist”的实际清理被推迟。在此窗口期间另一个进程可通过“bpf_trampoline_link_cgroup_shim”造成释放后使用。根据 Martin KaFai Lau 的建议，我创建了一个简单的修补程序。修复此缺陷 在“bpf_trampoline_link_cgroup_shim”中添加原子非零检查。如果 refcount 尚未归零则仅增加 refcount。测试我已通过在“bpf_shim_tramp_link_release”中添加延迟使此缺陷更容易触发来验证修复
    static void bpf_shim_tramp_link_release(struct bpf_link *link) { /* ... */ if (shim_link->trampoline) return; + msleep(100); WARN_ON_ONCE(bpf_trampoline_unlink_prog(&shim_link->link, shim_link->trampoline, NULL)); bpf_trampoline_put(shim_link->trampoline);在 修补程序之前通过类似于 KaiyanM 报告的调用跟踪运行 PoC 容易地重现崩溃几乎 100%。修补后即使在数百万次迭代之后该缺陷也不再发生。 (CVE-2026-23319)

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

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

  - i2ci801恢复 i2ci801用 I2C 总线锁定替换 acpi_lock 这会恢复提交 f707d6b9e7c18f669adfdb443906d46cfbaaa0c1。在极少情况下多个 udev 线程可在启动时收集 i801 设备信息并在一定程度上以并发方式遍历 i801_acpi_io_handler。第一个会注意到该区域被 acpi 保留用于防止进一步触摸。这最终会导致区域被取消注册。在取消注册区域之后但在可检查该区域是否取消注册之前第二个函数将进入 i801_acpi_io_handler。 i2c_lock_bus 依赖包含 lock_ops 的现已未注册的区域来锁定总线。最终结果是启动时出现内核错误并带有以下回溯[ 14.971872] ioatdma 0000:09:00.2启用设备 (0100 -> 0102) [ 14.971873] 缺陷内核空指针取消引用地址
    0000000000000000 [ 14.971880] #PF内核模式下的主管读取访问 [ 14.971884] #PF
    error_code(0x0000) - not-present 页面 [ 14.971887] PGD 0 P4D 0 [ 14.971894] Oops: 0000 [#1] PREEMPT SMP PTI [ 14.971900] CPU:5 PID: 956 Comm: systemd-udevd 未受感染 5.14. 0-611.5.1.el9_7.x86_64 #1 [14.971905] 硬件名称XXXXXXXXXXXXXXXXXXXXXXX BIOS 1.20.10。SV91 2023 年 1 月 30 日 [ 14.971908] RIP
    0010:i801_acpi_io_handler+0x2d/0xb0 [i2c_i801] [ 14.971929] 代码00 00 49 8b 40 20 41 57 41 56 4d 8b b8 30 04 00 00 49 89 ce 41 55 41 89 d5 41 89 d5 41 89 00 49 89 ce 41 55 41 89 d5 41 89 0010 0010 0010 00 55 4c 89 c5 53 89 fb <48> 8b 00 4c 89 c7 e8 18 61 54 e9 80 bd 80 04 00 00 00 75 09 4c 3b [ 14.971933] RSP: 0018:ffffbaa841483838 EFLAGS: 00010282 [14.971938] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9685e01ba568 [ 14.971941] RDX:
    0000000000000008 RSI0000000000000002 RDI0000000000000000 [ 14.971944] RBPffff9685ca22f028 R08
    ffff9685ca22f028 R09ffff9685ca22f028 [ 14.971948] R10000000000000000b R110000000000000580 R12
    0000000000000580 [ 14.971951] R13: 0000000000000008 R14: ffff9685e01ba568 R15: ffff9685c222f000 [14.971954] FS: 00007f8287c0ab40(0000) GS:ffff96a47f940000(0000) knlGS:0000000000000000 [ 14.971959] CS:
    0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 14.971963] CR2: 0000000000000000 CR3: 0000000168090001 CR4:
    00000000003706f0 [ 14.971966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [14.971968] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 14.971972] Call Trace: [14.971977] <TASK> [ 14.971981] ? show_trace_log_lvl+0x1c4/0x2df [ 14.971994] ? show_trace_log_lvl+0x1c4/0x2df [ 14.972003] ? acpi_ev_address_space_dispatch+0x16e/0x3c0 [ 14.972014] ?
    __die_body.cold+0x8/0xd [ 14.972021] ? page_fault_oops+0x132/0x170 [ 14.972028] ? exc_page_fault+0x61/0x150 [ 14.972036] ? asm_exc_page_fault+0x22/0x30 [ 14.972045] ? i801_acpi_io_handler+0x2d/0xb0 [i2c_i801] [ 14.972061] acpi_ev_address_space_dispatch+0x16e/0x3c0 [14.972069] ? __pfx_i801_acpi_io_handler+0x10/0x10 [i2c_i801] [ 14.972085] acpi_ex_access_region+0x5b/0xd0 [ 14.972093] acpi_ex_field_datum_io+0x73/0x2e0 [ 14.972100] acpi_ex_read_data_from_field+0x8e/0x230 [14.972106] acpi_ex_resolve_node_to_value+0x23d/0x310 [ 14.972114] acpi_ds_evaluate_name_path+ 0xad/0x110 [14.972121] acpi_ds_exec_end_op+0x321/0x510 [ 14.972127] acpi_ps_parse_loop+0xf7/0x680 [ 14.972136] acpi_ps_parse_aml+0x17a/0x3d0 [ [ 14.972143] acpi_ps_execute_method+0x137/0x270 [ 14.972150[01evaluate/0x270] acpi_ps_parse_aml+0x17a/0x3d0 [[ 14.972158] ] ] ] acpi_evaluate_object+0x134/0x2f0 [ 14.972164] acpi_evaluate_integer+0x50/0xe0 [ 14.972173] ? vsnprintf+0x24b/0x570 [ 14.972181] acpi_ac_get_state.part.0+0x23/0x70 [ 14.972189] get_ac_property+0x4e/0x60 [ 14.972195] power_supply_show_property+0x90/0x1f0 [ 14.972205] add_prop_uevent+0x29/0x90 [ 14.972213] power_supply_uevent +0x109/0x1d0 [ 14.972222] dev_uevent+0x10e/0x2f0 [ 14.972228] uevent_show+0x8e/0x100 [14.972236] dev_attr_show+0x19 ---truncated--- (CVE-2026-23369)

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

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

  - wifimt76mt7925修复 mt7925_mac_write_txwi_80211() 中可能的 oob 访问 在访问 mt7925_mac_write_txwi_80211 中的 mgmt 字段之前检查帧长度以避免可能的 oob 访问。
    (CVE-2026-23363)

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

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

  - blktrace在内部使用的可抢占上下文 tracing_record_cmdline() 中修复 __this_cpu_read/write
    per-CPU 变量 trace_cmdline_save 和 trace_save_cmdline() 上的 __this_cpu_read() 和 __this_cpu_write() 通过 lockdep_assert_preemption_disabled() 明确断言已禁用抢占。
    仅当关闭 preemption 时这些操作才安全因为它们设计用于从计划程序上下文probe_wakeup_sched_switch() / probe_wakeup()调用。 __blk_add_trace() 会在环缓冲区预留之前从 blk_tracer 路径中及早从完全启用了 preemption 的进程上下文中调用 tracing_record_cmdline(current)。使用 blktests/blktrace/002 时会触发以下内容
    blktrace/002sysfs 跟踪的 blktrace ftrace 损坏[失败] 运行时 0.367s ... 0.437s 在 dmesg 中发现某些内容[ 81.211018] 于 2026 年 2 月 25 日 22:24:33 运行 blktests blktrace/002 [ 81.239580] null_blk已创建磁盘 nullb1 [ 81.357294] BUG在抢占的 [00000000] 代码中使用 __this_cpu_read()dd/2516 [81.362842] 调用程序是 tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm dd 受感染GN 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] 受感染[N]=TEST [ 81.362878] 硬件名称
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [81.362881] 调用跟踪[ 81.362884] <TASK> [ 81.362886] dump_stack_lvl +0x8d/0xb0 ... 请参阅“/mnt/sda/blktests/results/nodev/blktrace/002.dmesg”以了解完整消息[ 81.211018] 于 2026 年 2 月 25 日 22:24:33 运行 blktests blktrace/002 [ 81.239580] null_blk创建了磁盘 nullb1 [ 81.357294] 缺陷使用
    抢占的 [00000000] 代码中的 __this_cpu_read() [ 81.362842] 调用者为 tracing_record_cmdline+0x10/0x40 [ 81.362872] CPU16 UID: 0 PID2516 Comm: dd TaintedGN 7.0.0-rc1lblk+ #84 PREEMPT完整 [ 81.362877] 受感染[N]=TEST [ 81.362878] 硬件名称QEMU Standard PC (i440FX + PIIX,1996)BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/ 01/2014 [ 81.362881] 调用跟踪[ 81.362884] [] <TASK> [ 81.362886] dump_stack_lvl+0x8d/0xb0 [ 81.362895] check_preemption_disabled+0xce/0xe0 [ 81.362902] tracing_record_cmdline+0x10/0x40 [ 81.362923]
    __blk_add_trace+0x307/0x5d0 [ 81.362934] ? lock_acquire+0xe0/0x300 [ 81.362940] ? iov_iter_extract_pages+0x101/0xa30 [ 81.362959] blk_add_trace_bio+0x106/0x1e0 [ 81.362968] submit_bio_noacct_nocheck+0x24b/0x3a0 [ 81.362979] ? lockdep_init_map_type+0x58/0x260 [ 81.362988] submit_bio_wait+0x56/0x90 [ 81.363009] __blkdev_direct_IO_simple+0x16c/0x250 [ 81.363026] ?
    __pfx_submit_bio_wait_endio+0x10/0x10 [ 81.363038] ? rcu_read_lock_any_held+0x73/0xa0 [ 81.363051] blkdev_read_iter+0xc1/0x140 [ 81.363059] vfs_read+0x20b/0x330 [ 81.363083] ksys_read+0x67/0xe0 [81.363090] do_syscall_64+0xbf/0xf00 [ 81.363102] entry_SYSCALL_64_after_hw/entry_SYSCALL_64_after_hw/ [ 81.363106] RIP: 0033:0x7f281906029d [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 0033 0e 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX
    0000000000000000 [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000 [00:000] [00:000RDI:0000 81.363123
    0000000000001000 R080000002863a10a81 R0900007f281915f000 [ 81.363124] R1000007f2818f77b60 R11
    0000000000000246 R120000559f8bfae000 [ 81.363126] R130000000000000000 R140000000000000000 R15
    000000000000000a [ 81.363142] </TASK> 相同的缺陷也会从 blk_add_trace_plug()、blk_add_trace_unplug() 和 blk_add_trace_rq() 路径触发。tracin 的用途 ---truncated--- (CVE-2026-23374)

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

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

  - ice将 XDP RxQ frag_size 从 DMA 写入长度更改为 xdp.frame_sz XDP RxQ 信息中 frag_size 字段的唯一用户是 bpf_xdp_frags_increase_tail()。显然需要整个 buff 大小而不是 DMA 写入大小。ice 驱动程序配置中的不同假设导致负 tailroom。当使用 XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver 测试并将数据包大小更改为 6912并将请求的偏移更改为极大的值例如 XSK_UMEM__MAX_FRAME_SIZE * 100时这允许触发内核错误。由于 ice 中 ZC 配置的其他 quirk在 ZC 模式中未观察到错误但 tailroom 增长在应该不会时仍然会失败。在 XDP RxQ 信息中使用填充队列缓冲区 truesize 而非 DMA 写入大小。通过使用新的帮助程序也修复 ZC 模式。 (CVE-2026-23377)

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

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

  - drbd修复本地读取错误中的空指针取消引用在 drbd_request_endio() 中READ_COMPLETED_WITH_ERROR 被传递到具有空 peer_device 的 __req_mod()__req_mod(req, what, NULL, &m); READ_COMPLETED_WITH_ERROR 处理程序随后无条件将此空 peer_device 传递至 drbd_set_out_of_sync()后者将其取消引用从而造成空指针取消引用。通过 first_peer_device(device) 获取 peer_device以此匹配 drbd_req_destroy() 处理相同情况的方式修复此问题。
    (CVE-2026-23285)

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

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

  - nfsd修复 nfsd_nl_threads_set_doit() 中的 cred ref 泄漏。 syzbot 报告了结构 cred 的内存泄漏。 [0] nfsd_nl_threads_set_doit() 将 get_current_cred() 传递到 nfsd_svc()但此后不会调用 put_cred()。cred 最终向下传递到 _svc_xprt_create()从而使用 struct svc_xprt 的 cred 调用 get_cred()。通过 get_current_cred() 获得的 refcount 所有权不会转移到任何地方而只是泄漏。 nfsd_svc() 也会从 write_threads() 调用但不会在该处升级 file->f_cred。
    从 sendmsg() 调用 nfsd_nl_threads_set_doit() 且 current->cred 没有消失。使用 nfsd_nl_threads_set_doit() 中的 current_cred() 即可。 [0]BUG内存泄漏未引用对象 0xffff888108b89480大小 184comm syz-executor, pid 5994, jiffies 4294943386 十六进制转储前 32 字节01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .. crc 369454a7kmemleak_alloc_recursive include/linux/kmemleak.h:44 [内联] slab_post_alloc_hook mm/slub.c:4958 [内联] slab_alloc_node mm/slub.c:5263 [内联] kmem_cache_alloc_noprof+0x412/0x580 mm/slub.c 5270 prepare_creds+0x22/0x600 kernel/cred.c:185 copy_creds+0x44/0x290 kernel/cred.c:286 copy_process+0x7a7/0x2870 kernel/fork.c:2086 kernel_clone+0xac/0x6e0 kernel/fork.c:2651 __do_sys_clone +0x7f/0xb0 kernel/fork.c:2792 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2026-23297)

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

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

  - InsightSoftwareConsortium ITK 中的整数溢出或回绕漏洞Modules/ThirdParty/Expat/src/expat 模块。此问题影响 之前的 ITK 2.7.1。 (CVE-2026-4739)

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

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

  - canems_usbems_usb_read_bulk_callback()检查消息的正确长度查看 USB urb 中的数据时actual_length 是传递给驱动程序的缓冲区大小而不是由驱动程序设置为缓冲区的最大大小。解析 ems_usb_read_bulk_callback() 中的消息时在解析消息开始时正确检查大小以确保其大小足够用于预期结构在消息结尾正确检查大小以确保不会溢出超过结尾下一条消息的缓冲区的编号。 (CVE-2026-23307)

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

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

  - canusbetas_es58x在读取批量回调中正确定位 urb 提交 urb 时即使用定位标记模式需要在提交前定位否则在调用 usb_kill_anchored_urbs() 时可能会泄漏。此逻辑已在驱动程序的其他位置正确完成但在读取批量回调中除外因此也在此处执行此逻辑。 (CVE-2026-23324)

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

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

  - drbd修复 drbd_al_begin_io_nonblock() 中的逻辑缺陷即使我们检查确保能够在保持 device->al_lock 自旋锁的同时执行 lc_get_cumulative()如果某些其他代码路径决定执行 lc_try_lock()则 lc_get_cumulative() 操作仍可能失败时机不当。如果发生这种情况我们记录了 enr=... 的逻辑缺陷但仍未返回错误。代码的其余部分现在假设此请求具有相关活动日志范围的引用。这些暗示在主动重新同步期间不保证重新同步与应用程序 IO 的相互独占。此时的潜在崩溃可能没有意识到这些盘区可能成为飞行中 IO 的目标并且需要重新同步以防万一。此外请求完成后将会放弃甚至不具有的活动日志引用这将在 lc_put() 中触发 BUG_ON(refcnt == 0)。修复不针对在正常操作期间无害的情况使内核崩溃不仅如此当受到在不活动盘区 %u 上调用的 al_complete_io() 影响时也捕获 e->refcnt == 0\n。也不要试图变得更机灵地猜测某些操作是否有效当发现无效时您会感到很奇怪。处理它可能有效也可能无效的事实。
    如果不是这样记住可能部分处于活动日志状态仅可能导致跨越范围边界的请求然后从 drbd_al_begin_io_nonblock() 返回错误代码。然后将从中断处恢复对同一请求的后者调用。 (CVE-2026-23356)

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

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

  - drm/vmwgfx返回 vmw_translate_ptr 函数中的正确值在 之前引用的补丁这些函数使用的查找函数会返回指针。已更改为另一个查找函数其返回错误代码其指针变为输出参数。未对查找失败时的错误路径进行更改以反映此更改并且代码继续返回目前未初始化的 PTR_ERR 指针。这可导致 vmw_translate_ptr 函数在实际失败时返回成功进而造成进一步的未初始化访问和 OOB 访问。 (CVE-2026-23317)

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

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

  - ksmbd 比较恒定时间中的 MAC 为防止时序攻击MAC 比较需要持续进行。
    将 memcmp() 替换为正确的函数 crypto_memneq()。 (CVE-2026-23364)

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

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

  - Bluetooth清除套接字析构函数中的错误队列通过 SO_TIMESTAMPING 启用 TX 时间戳时SKB 可能会排队到 sk_error_queue 中并留在这里直到消耗。如果用户空间始终无法读取时间戳或控制器被意外删除则这些 SKB 将泄漏。通过在受影响的蓝牙析构函数中为 sk_error_queue 添加 skb_queue_purge() 调用进行修复。RFCOMM 当前不使用 sk_error_queue。 (CVE-2026-23299)

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

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

  - canucan修复来自零长度消息的无限循环如果损坏的 ucan 设备收到消息长度字段设置为 0 的消息则驱动程序将在 ucan_read_bulk_callback() 中永远循环并使系统挂起。如果长度为 0，则仅跳过该消息并继续处理下一条消息。这已在过去的 kvaser_usb 驱动程序提交 0c73772cd2b8中得到修复因此kvaser_usbleaf修复命令解析器中可能存在的无限循环因此某处一定存在像这样的损坏设备。
    (CVE-2026-23298)

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

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

  - netusbkaweth 验证 USB 端点 kaweth 驱动程序应验证其正在探测的设备是否具有所需的正确数量和类型的 USB 端点然后再绑定该设备。如果恶意设备没有相同的 urb该驱动程序稍后会在其盲目访问这些端点时崩溃。 (CVE-2026-23312)

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

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

  - cxl修复运行 cxl-translate.sh 单元测试期间创建 nvdimm 对象 Found 的问题时nvdimm_bus 对象的争用。就在测试之前添加 3 秒睡眠似乎可以使问题相当一致地重现。cxl_translate 模块对 cxl_acpi 存在依存关系导致孤立的 nvdimm 对象在删除 cxl_acpi 后重新被探测。nvdimm_bus 对象由 cxl_nvb 对象在调用 cxl_acpi_probe() 时注册。由于缺少 nvdimm_bus 对象__nd_device_register() 在访问指向 &nvdimm_bus->dev 的 dev->parent 时将触发空指针取消引用。 [ 192.884510] 缺陷
    kernel 空指针取消引用地址000000000000006c [ 192.895383] 硬件名称QEMU Standard PC(Q35 + ICH9, 2009)BIOS edk2-20250812-19.fc42 08/12/2025 [ 192.897721] 工作队列cxl_port cxl_bus_rescan_queue [cxl_core] [ 192.899459] RIP: 0010:kobject_get+0xc/0x90 [ 192.924871] 调用跟踪 [192.925959] <TASK> [ 192.926976] ? pm_runtime_init+0xb9/0xe0 [ 192.929712]
    __nd_device_register.part.0+0x4d/0xc0 [libnvdimm] [ 192.933314] __nvdimm_create+0x206/0x290 [libnvdimm] [192.936662] cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem] [ 192.940245] cxl_bus_probe+0x1a/0x60 [cxl_core]192.943349] real_probe+0xde/0x380 此修补程序也依赖之前的变更其中从 drivers/cxl/pmem.c 而非 drivers/cxl/core.c 调用 devm_cxl_add_nvdimm_bridge() 以确保 cxl_acpi 对 cxl_pmem 的依存关系。 1. 将 cxl_nvb 的 probe_type 设置为 PROBE_FORCE_SYNCHRONOUS以确保在调用 add_device() 时同步探测驱动程序。 2. 添加签入
    __devm_cxl_add_nvdimm_bridge() 以确保在 cxl_acpi_probe() 期间附加 cxl_nvb 驱动程序。 3.
    获取 devm_cxl_add_nvdimm() 中的 cxl_root uport_dev 锁定和 cxl_nvb->dev 锁定然后检查 nvdimm_bus 是否有效。 4. 将 cxl_nvdimm 标记设置为 CXL_NVD_F_INVALIDATED以便 cxl_nvdimm_probe() 将以
    -EBUSY。一旦 nvdimm_bus 消失，cxl_nvdimm 设备的删除应阻止任何孤立的设备进行探测。 [ dj修复了 0day 报告的 kdoc 问题。 ] [ dj修复出错时的 cxl_nvb 引用泄漏。
    Gregory (kreview-0811365) ] (CVE-2026-23348)

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

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

  - 错误授权 (CWE-863) 中存在错误授权 (CWE-863) 漏洞当使用 OpenWire 协议的应用程序尝试在具有 createDurableQueue 的经身份验证用户不存在的地址上创建非持久 JMS 主题订阅时Apache ActiveMQ Artemis 中存在 OpenWire 协议的应用程序权限但没有 createAddress 权限并且地址自动创建被禁用。在此情况下系统会创建一个临时地址但创建非持久订阅的尝试反而会失败因为用户无权创建相应的地址。当 OpenWire 连接关闭时该地址将被删除。该问题影响 Apache Artemis从 2.50.0 到 2.52.0Apache ActiveMQ Artemis从 2.0.0 到 2.44.0。建议用户升级到修复了此问题的版本 2.53.0。(CVE-2026-32642)

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

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

  - netethernetmtk_eth_soc如果 mtk_xdp_setup() 中出错将 prog ptr 重置为 old_prog 将 eBPF 程序指针重置为 old_prog并且如果 mtk_xdp_setup() 中的 mtk_open 例程失败不减少其 ref-count。 (CVE-2026-23284)

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

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

  - canmcp251x修复 mcp251x_open 错误路径中的死锁 mcp251x_open() 函数在持有 mpc_lock 互斥体的情况下调用其错误路径中的 free_irq()。但如果已发生中断中断处理程序将等待 mpc_lock且 free_irq() 将死锁等待处理程序完成。此问题与 commit 7dd9c26bd6cf 中已修复的问题类似可以mcp251x如果在 mcp251x_open 期间发生中断则修复死锁但针对错误路径。要解决此问题在释放锁定后移动对 free_irq() 的调用。提前设置“priv->force_quit = 1”可确保 IRQ 处理程序在获得锁定后立即退出。 (CVE-2026-23357)

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

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

  - Squid 是 Web 的缓存代理。在版本 7.5之前由于在预期生命周期内过早释放资源以及堆释放后使用缺陷Squid 在处理 ICP 流量时容易遭受拒绝服务。此问题允许远程攻击者对使用 ICP 协议的 Squid 服务执行可靠且可重复的拒绝服务攻击。此攻击仅限于明确启用 ICP 支持即配置非零“icp_port”的 Squid 部署。此问题_无法_通过使用“icp_access”规则拒绝 ICP 查询来缓解。已在 Squid 版本 7.5中修复此缺陷。 (CVE-2026-32748)

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

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

  - wificfg80211取消 wiphy_unregister() 中的 rfkill_block 作业cfg80211_shutdown_all_interfaces 中发现一个释放后使用错误 syzkaller: BUGKASANcfg80211_shutdown_all_interfaces+0x213/0x220 在地址 ffff888d9812a7881812a7881812a7881812a788d9812a788d9812a7812a788d9812a7812a7812a7812a7812a7812a7812a7812a7812a7812a7812a2a72a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a212a212a212a212a212 task kworker/0:5/5326 CPU0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT自主硬件名称QEMU Standard PC（i440FX + PIIX，1996）、BIOS 1.15.0-1 04/01/2014 Workqueue: events cfg80211_rfkill_block_work Call Trace: <TASK> dump_stack_lvl+0x116/0x1f0 print_report+0xcd/0x630 kasan_report+0xe0/0x110 cfg80211_shutdown_all_interfaces+0x213/0x220 cfg80211_rfkill_block_work+0x1e/0x30 process_one_work+0x9cf/0x1b70 worker_thread+0x6c8/ 0xf10 kthread+0x3c5/0x780 ret_from_fork+0x56d/0x700 ret_from_fork_asm+0x1a/0x30 </TASK> 出现此问题的原因是注销 wiphy 时未取消 rfkill_block 工作。若要修复此问题请取消 wiphy_unregister() 中的相应工作。由 Linux Verification Center (linuxtesting.org) 通过 Syzkaller 发现。 (CVE-2026-23336)

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

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

  - netsched避免无锁 qdisc 的 qdisc_reset_all_tx_gt() 与出列争用减少实际 tx 队列数量时netif_set_real_num_tx_queues() 会调用 qdisc_reset_all_tx_gt() 以刷新将不再使用的队列的 qdiscs。 qdisc_reset_all_tx_gt() 目前将 qdisc_reset() 与 qdisc_lock() 序列化。然而对于无锁的 qdiscs出列路径由 qdisc_run_begin/end() 使用 qdisc->seqlock 序列化因此 qdisc_reset() 可与 __qdisc_run() 同时运行并在仍在出列时释放 skb从而导致 UAF。这可以通过在频繁更改队列对数量的同时施加大量流量轻松重现例如 virtio-netiperf3 -ub0 -c $peer -t 0 & while :; do ethtool -L eth0合并1 ethtool -L eth0合并2完成在启用 KASAN 的情况下这会导致类似以下的报告
    缺陷KASAN__qdisc_run+0x133f/0x1760 中的 slab 释放后使用 ... 调用跟踪 <TASK>...
    __qdisc_run+0x133f/0x1760 __dev_queue_xmit+0x248f/0x3550 ip_finish_output2+0xa42/0x2110 ip_output+0x1a7/0x410 ip_send_skb+0x2e6/0x480 udp_send_skb+0xb0a/0x1590sx3gudp_ ...0x1590sx3gudp_ ...
    </TASK> 由 cpu 5 上的任务 1270 在 44.558414s分配... alloc_skb_with_frags+0x84/0x7c0 sock_alloc_send_pskb+0x69a/0x830 __ip_append_data+0x1b86/0x48c0 ip_make_skb+0x1e8/0x2b0 udp_sendmsg/0x1fc360 ... Freed by task 1306 on cpu 3 at 44.558445s: ... kmem_cache_free+0x117/0x5e0 pfifo_fast_reset+0x14d/0x580 qdisc_reset+0x9e/0x5f0 netif_set_real_num_tx_queues+0x303/0x840 virtnet_set_channels+0x1bf/0x260 [virtio_net] ethnl_set_channels+0x684/0xae0 ethnl_default_set_doit+0x31a /0x890 ... 通过对 TCQ_F_NOLOCK qdiscs 进行 qdisc->seqlock匹配已由 dev_reset_queue() 使用的序列化模型可针对无锁出列路径序列化 qdisc_reset_all_tx_gt()。此外重置后清除 QDISC_STATE_NON_EMPTY以便 qdisc 状态反映空队列从而避免不必要的重新计划。 (CVE-2026-23340)

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

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

  - bpf、arm64强制 JIT 缓冲区执行 8 字节对齐以防止原子拆分 struct bpf_plt 包含 u64 目标字段。目前BPF JIT 分配器请求 JIT 缓冲区的 4 字节对齐 (sizeof(u32))。因为JIT 缓冲区的基址可能是 4 字节对齐的例如以 0x4 或 0xc 结尾build_plt() 中的相关填充逻辑不能确保目标位于 8 字节边界上。这导致两个问题1. 取消引用结构时UBSAN 报告未对齐访问警告。 2. 更严重的是当 JIT 代码执行 ldr 时通过 bpf_arch_text_poke() 中的 WRITE_ONCE() 并发更新目标。在 arm64 中仅当 64 位加载/存储进行 64 位对齐时才保证其为单一副本原子性。未对齐的目标可能会造成 JIT 跳转到损坏的地址从而导致读取损坏。通过将 bpf_jit_binary_pack_alloc() 中的分配对齐要求提高到 8 字节 (sizeof(u64)) 来修复此问题。这将 JIT 缓冲区的基础定位到 8 字节边界允许 build_plt() 中的相对填充数学函数可以正确对齐目标字段。 (CVE-2026-23383)

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

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

  - net/schedact_ife修复 metalist 更新行为 每当 ife 操作替换更改 metalist 时当前 ife 代码都附加新的元数据而不是替换 metalist 上的旧数据。
    除了不当行为之外这还可能导致将元数据无限制地添加到 metalist 从而在运行编码 op 时造成越界错误 [ 138.423369][ C1] =========== ================================================== ===== [ 138.424317][ C1] BUGKASANife_tlv_meta_encode 中的 slab 越界 (net/ife/ife.c:168) [ 138.424906][ C1] 地址 ffff8880077f4ffe 处大小为 4 的写入按任务 ife_out_out_bou/255 [ 138.425778][ C1] CPU1 UID0 PID255 Comm
    ife_out_out_bou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full) [ 138.425795][ C1] 硬件名称Bochs Bochs，BIOS Bochs 01/01/2011 [ 138.425800][ C1] 调用跟踪[ 138.425804][ C1] <IRQ> [138.425808][ C1] dump_stack_lvl (lib/dump_stack.c:122) [ 138.425828][ C1] print_report (mm/kasan/report.c:379 mm/kasan/report.c [482 138.425839[C1] srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:95标识符 1) ./include/linux/rcupdate.h:975 (标识符 1) ./include/linux/mmzone.h:2207 (标识符 1) ) arch/x86/mm/physaddr.c:54 (标识符 1)) [ 138.425853][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425859][ C1] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:597) [138.425868][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425878][ C1] kasan_check_range (mm/kasan/generic.c:186辨别器 1) mm/kasan/generic.c:200 (辨别器 1)) [ 138.425884][ C1]
    __asan_memset (mm/kasan/shadow.c:84 (disabilities 2)) [ 138.425889][ C1] ife_tlv_meta_encode (net/ife/ife.c:168) [ 138.425893][ C1] ? ife_tlv_meta_encode (net/ife/ife.c:171) [ 138.425898][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ife_encode_meta_u16 (net/sched/act_ife.c:57) [ 138.425910][ C1] ? __pfx_do_raw_spin_lock (kernel/locking/spinlock_debug.c:114) [ 138.425916][ C1] ? __asan_memcpy (mm/kasan/shadow.c:105标识符 3) [ 138.425921][ C1] ?
    __pfx_ife_encode_meta_u16 (net/sched/act_ife.c:45) [ 138.425927][ C1] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcf_ife_act (net/sched/act_ife.c:847 net/sched/act_ife.c:879) 修复此问题将替换行为通过将 metalist 添加到 ife rcu 数据结构。 (CVE-2026-23378)

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

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

  - NGINX Open Source 和 NGINX Plus 在 ngx_http_mp4_module 模块中存在一个漏洞可能允许攻击者使用特别构建的 MP4 触发缓冲区过度读取或 NGINX 工作线程内存过度写入导致其终止或可能执行代码。文件。如果 NGINX Open Source 和 NGINX Plus 是通过 ngx_http_mp4_module 模块构建并且在配置文件中使用了 mp4 指令此问题会影响。此外仅在攻击者可触发对使用 ngx_http_mp4_module 模块对特别构建的 MP4 文件的处理时才可能发生攻击。注意：不评估已达到技术支持结束日期 (EoTS) 的软件版本。(CVE-2026-32647)

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

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

  - Active Support 是一个工具包，包含从 Rails 框架中提取的支持库和 Ruby 核心扩展。在版本 8.1.2.1、 8.0.4.1和 7.2.3.1之前Active Support 数字帮助程序接受包含科学计数法的字符串例如“1e10000”“BigDecimal”会将其扩展为极大的十进制表示。当扩展的数字被格式化时这可造成过多内存分配和 CPU 消耗从而可能导致 DoS 漏洞。版本 8.1.2.1、 8.0.4.1和 7.2.3.1 包含修补程序。 (CVE-2026-33176)

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

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

  - platform/x86dell-wmi-sysman不以十六进制转储明文密码数据 set_new_password() 以十六进制转储整个缓冲区其中包含明文密码数据包括当前密码和新密码。删除十六进制转储以避免泄漏凭据。 (CVE-2026-23370)

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

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

  - Squid 是 Web 的缓存代理。在低于版本 7.5的版本中由于堆释放后使用Squid 在处理 ICP 流量时容易遭受拒绝服务攻击。此问题允许远程攻击者对使用 ICP 协议的 Squid 服务执行可靠且可重复的拒绝服务攻击。
    此攻击仅限于明确启用 ICP 支持即配置非零“icp_port”的 Squid 部署。此问题_无法_通过使用“icp_access”规则拒绝 ICP 查询来缓解。版本 7.5 包含修补程序。 (CVE-2026-33526)

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

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

  - i40e修复 napi 轮询跟踪点中的 preempt 计数泄漏。在跟踪点分配中使用 get_cpu() 会导致明显的 preempt 计数泄漏因为没有任何东西调用 put_cpu() 来撤消这一泄漏 softirqhuh进入了 preempt_count 00000100 的 softirq 3 NET_RX但退出了 00000101 ? 显然在过去 3 年多的时间里进行了大量的测试... 改用 smp_processor_id()。 (CVE-2026-23313)

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

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

  - wifimt76mt7996修复 mt7996_mac_write_txwi_80211() 中可能的 oob 访问 在访问 mt7996_mac_write_txwi_80211 中的 mgmt 字段之前检查帧长度以避免可能的 oob 访问。
    (CVE-2026-23325)

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

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

  - smb客户端不在 cifs_set_cifscreds 中记录明文凭据启用调试日志记录时cifs_set_cifscreds() 会记录密钥负载并暴露明文用户名和密码。删除调试日志以避免凭据泄露。 (CVE-2026-23303)

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

ID	名称	严重性
303729	Linux Distros 未修补的漏洞：CVE-2026-3119	medium
303728	Linux Distros 未修补的漏洞：CVE-2026-23321	medium
303727	Linux Distros 未修补的漏洞：CVE-2026-23332	medium
303726	Linux Distros 未修补的漏洞：CVE-2026-23371	high
303725	Linux Distros 未修补的漏洞：CVE-2026-23300	medium
303724	Linux Distros 未修补的漏洞：CVE-2026-23292	medium
303723	Linux Distros 未修补的漏洞：CVE-2026-23318	high
303722	Linux Distros 未修补的漏洞：CVE-2026-3104	high
303721	Linux Distros 未修补的漏洞：CVE-2026-3591	medium
303720	Linux Distros 未修补的漏洞：CVE-2026-23308	high
303719	Linux Distros 未修补的漏洞：CVE-2026-23334	medium
303718	Linux Distros 未修补的漏洞：CVE-2026-23339	medium
303717	Linux Distros 未修补的漏洞：CVE-2026-23352	high
303716	Linux Distros 未修补的漏洞：CVE-2026-23343	high
303715	Linux Distros 未修补的漏洞：CVE-2026-23279	medium
303714	Linux Distros 未修补的漏洞：CVE-2026-23290	medium
303712	Linux Distros 未修补的漏洞：CVE-2026-23282	high
303711	Linux Distros 未修补的漏洞：CVE-2026-23346	medium
303710	Linux Distros 未修补的漏洞：CVE-2026-23319	medium
303709	Linux Distros 未修补的漏洞：CVE-2026-23369	medium
303708	Linux Distros 未修补的漏洞：CVE-2026-23363	high
303707	Linux Distros 未修补的漏洞：CVE-2026-23374	high
303705	Linux Distros 未修补的漏洞：CVE-2026-23377	high
303704	Linux Distros 未修补的漏洞：CVE-2026-23285	medium
303703	Linux Distros 未修补的漏洞：CVE-2026-23297	medium
303702	Linux Distros 未修补的漏洞：CVE-2026-4739	critical
303701	Linux Distros 未修补的漏洞：CVE-2026-23307	high
303700	Linux Distros 未修补的漏洞：CVE-2026-23324	high
303699	Linux Distros 未修补的漏洞：CVE-2026-23356	medium
303698	Linux Distros 未修补的漏洞：CVE-2026-23317	high
303697	Linux Distros 未修补的漏洞：CVE-2026-23364	high
303696	Linux Distros 未修补的漏洞：CVE-2026-23299	high
303695	Linux Distros 未修补的漏洞：CVE-2026-23298	medium
303694	Linux Distros 未修补的漏洞：CVE-2026-23312	medium
303692	Linux Distros 未修补的漏洞：CVE-2026-23348	medium
303691	Linux Distros 未修补的漏洞：CVE-2026-32642	low
303690	Linux Distros 未修补的漏洞：CVE-2026-23284	medium
303689	Linux Distros 未修补的漏洞：CVE-2026-23357	medium
303688	Linux Distros 未修补的漏洞：CVE-2026-32748	high
303687	Linux Distros 未修补的漏洞：CVE-2026-23336	high
303686	Linux Distros 未修补的漏洞：CVE-2026-23340	high
303685	Linux Distros 未修补的漏洞：CVE-2026-23383	high
303684	Linux Distros 未修补的漏洞：CVE-2026-23378	high
303683	Linux Distros 未修补的漏洞：CVE-2026-32647	high
303682	Linux Distros 未修补的漏洞：CVE-2026-33176	high
303681	Linux Distros 未修补的漏洞：CVE-2026-23370	high
303680	Linux Distros 未修补的漏洞：CVE-2026-33526	critical
303679	Linux Distros 未修补的漏洞：CVE-2026-23313	high
303678	Linux Distros 未修补的漏洞：CVE-2026-23325	high
303677	Linux Distros 未修补的漏洞：CVE-2026-23303	high

检测

Nessus 的 Misc. 系列

medium

medium

medium

high

medium

medium

high

high

medium

high

medium

medium

high

high

medium

medium

high

medium

medium

medium

high

high

high

medium

medium

critical

high

high

medium

high

high

high

medium

medium

medium

low

medium

medium

high

high

high

high

high

high

high

high

critical

high

high

high