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

  - rxrpc：通过将数据复制到 recvmsg 中的缓冲区，修复 DATA 解密与 splice（） 这改进了针对 .CVE-2026-43500 通过去除 I/O 线程中的数据包共享，并无条件地将数据包内容提取到反弹缓冲区（该缓冲区）中进行解密，修复由 splice（） 本地传输的数据包就地解密而造成的页面缓存损坏。recvmsg（）（或内核等效项）然后将数据从 bounce 缓冲区复制到目标缓冲区。然后，sk_buff保持不修改。这还有一个额外的优势，即数据包随后以加密算法直接处理所需的正确对齐方式排列在缓冲区中。加密的性能似乎确实快了一些，而且令人惊讶的是，未加密的性能似乎没有太大变化
    - 可能是因为降低了 I/O 线程的复杂性。另一个优点是 I/O 线程不必复制数据包，这会减慢数据包分发、ACK 生成等速度。缓冲区属于调用，最初以 2K（足够大小容纳整个巨型子数据包）分配，但如果需要，缓冲区的大小将会增加。但是，为了完成这项工作，MSG_PEEK可能会导致将较早的数据包解密到缓冲区中，在这种情况下，较早的数据包将需要为后续的 recvmsg（） 重新解密。请注意，rx_pkt_offset现在可以合法地将 0 视为有效偏移，因此切换为使用 USHRT_MAX 来表示无效偏移。另请注意，我通常更愿意将当前sk_buff的缓冲区替换为大小合适的新 kmalloc'd 缓冲区，放弃旧的数据和碎片，因为这样可以更轻松地处理MSG_PEEK并消除重新解密问题，但这看起来是一件相当复杂的事情。skb_morph（） 看起来符合我想要的一半，但我不想分配新的sk_buff。（CVE-2026-64026）

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

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

  - netfilter：nf_tables：修复同一寄存器操作中的 dst 损坏 对于 lshift 和 rshift，移位操作在 32 位字上循环执行。循环计算移位值并将其写入 dst，然后立即从 src 读取以计算下一次迭代的进位。由于 src 和 dst 可能指向相同的内存位置，因此无法使用新修改的 dst 值而非原始 src 值正确计算进位。添加一个临时本地变量来在写入 dst 之前缓存原始值并将其用于进位计算可解决该问题。此外，所有类型的操作（包括字节顺序）都会拒绝控制平面的部分重叠。这是用下列字节码测试的： 表 test_table ip 标志 0 使用 1 句柄 1 ip test_table test_chain 使用 3 类型筛选器挂钩输入 prio 0 策略接受数据包 0 字节 0 标志 1 ip test_table test_chain 2 [immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = （ reg 1 << 0x08000000 ） ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = （ reg 1 << 0x08000000 ） ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 字节 1917798 ] （CVE-2026-64006）

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

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

  - Bluetooth：HIDP：修复 hidp_input_report（） 中缺少的长度检查 hidp_input_report（） 从 skb 读取键盘和鼠标负载数据，而无需事先验证 skb->len 是否包含足够的数据。
    hidp_recv_intr_frame（） 在调度到 hidp_input_report（） 之前拉取 1 字节的 HIDP 标头。如果已配对设备发送截断的数据包，则处理程序会读取超出有效的 skb 数据，从而导致 skb 数据的越界读取。OOB 字节可被解释为幻影按键或虚假鼠标移动。请用 skb_pull_data（） 调用替换开放代码的长度跟踪和指针算法。
    skb_pull_data（） 如果请求的字节不存在则返回 NULL，因此不需要手动大小变量和单独的 skb->len 保护。（CVE-2026-63947）

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

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

  - usb：gadget：f_fs：仅复制短 ep0 读取上接收到的字节 ffs_ep0_read（） 使用 kmalloc（）（而非 kzalloc）以来自设置数据包的长度值分配其控制 OUT 数据缓冲区，然后将该完整长度复制到用户空间，而不管实际收到的字节数为何：data = kmalloc（len， GFP_KERNEL）;...
    ret = __ffs_ep0_queue_wait（ffs， data， len）;if （（ret > 0） & （copy_to_user（buf， data， len））） ret =
    -EFAULT;__ffs_ep0_queue_wait（） 返回 req->actual，在短控制 OUT 传输中严格小于 len。copy_to_user（） 调用仍然会复制 len 字节，因此在短 OUT 时，kmalloc（） 缓冲区的最后一个 （len - ret） 字节（未初始化的 slab 残余）会传递到 FunctionFS 后台程序。
    短 ep0 OUT 完成是指定的 USB 控制传输行为，由树内 UDC 生成：* dwc2 继续执行 ep0 DATA OUT 的 req->actual < req->length（short-not-ok 是唯一的 ep0-OUT 停止路径）。* aspeed_udc在 ep->ep.maxpacket rx_len <结束 ep0 OUT。* renesas_usbf记录 ep0 短数据包并完成请求。* dwc3 在短 IN 上停止，但在短 OUT 上不会停止。因此，短 ep0 OUT 不是 UDC 损坏的证据;这是f_fs必须应对的正常情况。drivers/usb/gadget/legacy/inode.c 中的同级 gadgetfs 实现已通过 copy_to_user（） 之前的 min（len， dev->req->actual） 正确执行此操作。此修补程序将 f_fs.c 引入相同的安全模式，而不是在防御层进行裁剪。从 FunctionFS 设备节点访问该缺陷，在实际部署中，该节点由特权小工具后台程序（adbd、UMS、复合小工具服务等）拥有;无法从非特权用户空间访问。Linux 主机堆栈通常会在 short-wLength 控制 OUT 到达小工具之前将其拒绝，因此重现此缺陷需要绕过该主机端检查的版本。
    绕过到位后，64 字节安装程序上的 1 字节负载会在后台程序的读取缓冲区中产生 63 字节的非金丝雀碎片残余。通过仅将 ret（实际收到）字节复制到用户空间来修复。
    (CVE-2026-63895)

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

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

  - test_kprobes：在测试运行之间清除 kprobes 运行两次 kprobes 健全测试会使所有测试失败，并最终造成内核崩溃。[root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # 总计：pass：5 fail：0 skip：0 total：5 ok 1 kprobes_test [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ... # test_kprobe： EXPECTATION FAILED at lib/tests/test_kprobes.c：64 Expected 0 == register_kprobe（&kp），but register_kprobe（&kp） == -22 （0xffffffffffffffea） ... 无法处理内核分页请求... 测试套件将数个 kprobes 和 kretprobes 定义为在测试运行间保留的静态变量。在register_kprobe和unregister_kprobe之后，kprobe 包含一些剩余数据，必须先清除这些数据，然后才能再次注册 kprobe。测试正在设置symbol_name以定义探头位置。必须清除地址和标记。现有代码在后续测试之间清除某些探测，但不会在两次测试运行之间清除。上一次测试运行的剩余数据使注册在下一次测试中失败。将所有 kprobe 的清除移至 kprobes_test_init，此函数会在每次测试（包括测试运行的第一次测试）之前调用。（CVE-2026-64163）

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

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

  - netfilter：ebtables：移至两阶段删除方案 与之前针对 x_tables 的修补程序一样，ebtables 中也遵循相同的模式。我们无法重用 xt 帮助程序：ebt_table struct 布局不兼容。table->ops 分配现在已完成，同时仍保留 ebt 互斥体，以确保永远不会暴露部分填充的表结构。（CVE-2026-64077）

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

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

  - netfilter：x_tables：添加并使用 xtables_unregister_table_exit 之前的变更添加了xtables_unregister_table_pre_exit以将表与数据包路径分离，以及将其与活动表列表断开链接。对于 rmmod，对此表执行 set/getsockopt 的用户空间将无法重新实例化该表：1. 已删除幼虫表 2.现有的实例化表不再位于 XT pernet 表列表中。这添加了第二阶段帮助程序：从濒死列表中取消表的链接，释放挂钩 ops（如果有）并执行审计通知。它替换 xt_unregister_table（）。
    (CVE-2026-64078)

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

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

  - powerpc/hv-gpci：修复 sysfs 显示路径中的 preempt 计数泄漏 hv-gpci 中的四个 sysfs show（） 回调采用 get_cpu_var（hv_gpci_reqb）（调用 preempt_disable（）），但仅在“out：”标签下的错误路径上调用匹配的 put_cpu_var（）。每次成功读取都会泄露一个 preempt_disable（）：
    processor_bus_topology_show（） processor_config_show（） affinity_domain_via_virtual_processor_show（） affinity_domain_via_domain_show（） （affinity_domain_via_partition_show（） 已正确。）在 CONFIG_PREEMPT=y 内核中，反复读取会引发preempt_count，并最终返回仍禁用优先权的用户空间。然后，下一个用户模式页面错误命中 faulthandler_disabled（） == 1，被强制至 SIGSEGV，而生成的 coredump 在 call_usermodehelper_exec -> wait_for_completion_state -> schedule： BUG： scheduling while atomic：
    <task>/<pid>/0x00000004 ... __schedule_bug+0x6c/0x90 __schedule+0x58c/0x13a0 schedule+0x48/0x1a0 schedule_timeout+0x104/0x170 wait_for_completion_state+0x16c/0x330 call_usermodehelper_exec+0x254/0x2d0 vfs_coredump+0x1050/0x2590 get_signal+0xb9c/0xc80 do_notify_resume+0xf8/0x470 添加一个 out_success 标签，该标签在返回字节计数前调用 put_cpu_var（），从而镜像 affinity_domain_via_partition_show（）。
    (CVE-2026-64070)

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

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

  - vsock/virtio：填充 zerocopy skb 前绑定 uarg virtio_transport_send_pkt_info（） 在进入发送循环前分配或重用 zerocopy uarg，但 virtio_transport_alloc_skb（） 在继承该 uarg 之前仍然填充 skb。当固定缓冲区矢量 zerocopy 命中 MAX_SKB_FRAGS 时，io_sg_from_iter（） 可能会部分附加受管 frag 并返回 -EMSGSIZE。回滚路径调用 kfree_skb（） 以释放携带 SKBFL_MANAGED_FRAG_REFS 但不携带 uarg 的 skb，因此 skb_release_data（） 会变成普通的 frag unref。将 uarg 传递到 virtio_transport_alloc_skb（） 并在 virtio_transport_fill_skb（） 之前绑定它。这可以保持控制或无负载 skb，同时确保成功和回滚共享一个生命周期规则。（CVE-2026-63970）

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

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

  - rbd：消除 unmap 上 lock_dwork 耗尽中的争用 鉴于 rbd_lock_add_request（） 和 rbd_img_exclusive_lock（） 的写入方式，lock_dwork 可能（重新）排队的时间超过实际需要的次数：例如，当我们代表另一个 I/O 请求在 rbd_acquire_lock（） 中间时，有一个新的 I/O 请求传入。这是正常情况，且通过 rbd_release_lock（） 抢先取消lock_dwork在正常操作中是安全的。一个更成问题的例子是 maybe_kick_acquire（）： if （have_requests || delayed_work_pending（&rbd_dev->lock_dwork）） { dout（%s rbd_dev %p kicking lock_dwork\n， __func__， rbd_dev）; mod_delayed_work（rbd_dev->task_wq， &rbd_dev->lock_dwork， 0）; }在 delayed_work_pending（） 返回 true 后立即取消 lock_dwork 并让 mod_delayed_work（） 重新排队并非不现实。这是一场经典的 TOCTOU 比赛。在取消映射图像时，隐式假设超过来自 rbd_dev_image_unlock（） 的返回点后没有任何自我启动的排他锁活动，如果碰巧持有锁，则解锁该锁。此解锁被认为是最终的，并且lock_dwork（以及所有其他独占锁定任务，实际上）预计不会再次排队。
    但是，lock_dwork仅在 cancel_tasks_sync（） 中（即取消映射序列的后面）中取消，最重要的是，取消实际上可能被 maybe_kick_acquire（） 无效化。这可能导致 rbd_dev_device_release（） 和 rbd_dev_image_release（） 运行后执行 rbd_acquire_lock（），并释放和/或重置一堆东西。其中一种可能的失败模式是违反rbd_assert（rbd_image_format_valid（rbd_dev->image_format））;在 rbd_dev_header_info（） 中，通过从 rbd_post_acquire_action（） 的 rbd_dev_refresh（） 调用。重做独占锁定任务耗尽，以提供更合理的语义，并尝试满足关于 rbd_dev_image_unlock（） 的假设。（CVE-2026-64112）

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

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

  - netfs：修复 netfs_read_to_pagecache（） 以在子请求失败时暂停 修复 netfs_read_to_pagecache（），以便在已发出的子请求失败时暂停生成新的子请求。（CVE-2026-64066）

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

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

  - blk-mq：弹出缓存的请求（如果可用） 当将 bio 提交到 blk-mq 时，如果任务应该在预览缓存的请求之后休眠，但在弹出之前，插头将刷新并调用blk_mq_free_plug_rqs，从而释放cached_rqs。这造成释放后使用缺陷。如果适合使用，通过在任何可能的阻止调用之前弹出缓存请求来修复此问题。首先弹出此请求会保留队列引用，因此可避免与队列冻结发生任何序列化争用，并可以安全地继续将该请求分派到驱动程序。这可能会增加从驱动程序想要冻结其队列到停止调度请求的计时时段。不过，这种情况不在快速路径上，驱动程序无论如何都需要在冻结请求期间适当处理请求。缺点是，当我们执行生物插头合并时，需要单独释放弹出的元素。以后无论如何都必须释放缓存的请求，但此修补程序在构建插头列表时实现此操作，而不是在刷新它之后。
    (CVE-2026-64017)

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

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

  - netfs：修复 ->remote_i_size 和 ->zero_point 中潜在的撕裂 修复使用
    ->remote_i_size 和 ->zero_point，方法是复制 i_size_read（） 和 i_size_write（），并使用与 i_size 相同的 seqcount。我们需要确保 netfslib 及其使用它的文件系统在更新任何大小时始终保持i_lock，以防止损坏i_size_seqcount。（CVE-2026-64160）

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

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

  - af_unix：修复 unix_stream_data_wait（） 中对 tail->len 的 UAF 读取 unix_stream_data_wait（） 在不保持任何阻止该队列上的 SKB 出列和释放的锁定的情况下执行 skb_peek_tail（&sk->sk_receive_queue）。自提交 79f632c71bea 以来一直如此（unix/stream：修复了使用大于队列中数据的偏移进行的扫视）。这样做的第一个后果是指针比较 'tail ！= last' 可能是假的，即使 'last' 在语义上指的是已经释放的 SKB，而 'tail' 是在同一地址分配的新 SKB;这可导致 unix_stream_data_wait（） 在新数据到达后错误地继续阻断，但仅限于奇怪的情况下，即窥视 recv（） 和同一套接字上的普通 recv（） 正在争用，这可能不是真正的问题。但自从提交 2b514574f7e8（net：af_unix：
    实现 stream af_unix 套接字的 splice），“tail”实际会取消引用，这可在以下争用情况下造成 UAF（其中 test_setup（） 以单线程运行，然后 test_thread1） 和 test_thread2（） 在两个线程中并发运行： ''' static int socks[2]; void test_setup（void） {socketpair（AF_UNIX， SOCK_STREAM， 0， socks）; send（socks[1]， A， 1, 0);int peekoff = 1;
    setsockopt（socks[0]， SOL_SOCKET， SO_PEEK_OFF， &peekoff， sizeof（peekoff））;} void test_thread1（void） { char dummy; recv（socks[0]， &dummy， 1， MSG_PEEK）; } void test_thread2（void） { char dummy; recv（socks[0]， &dummy， 1， 0）; shutdown（socks[1]， SHUT_WR）; } ''' when race： ''' thread1 thread2 unix_stream_read_generic mutex_lock（&u->iolock） skb_peek（&sk->sk_receive_queue） skb_peek_next（skb， &sk->sk_receive_queue） mutex_unlock（&u->iolock） unix_stream_read_generic unix_state_lock（sk） skb_peek（&sk->sk_receive_queue） unix_state_unlock（sk） unix_stream_data_wait unix_state_lock（sk） tail = skb_peek_tail（&sk->sk_receive_queue） spin_lock（&sk->sk_receive_queue.lock） __skb_unlink（skb， &sk->sk_receive_queue） spin_unlock（&sk->sk_receive_queue.lock） consume_skb（skb） [释放 SKB] 'tail ！= last'：false 'tail'：true 'tail->len ！= last_len' ***UAF*** ''' 通过删除 tail->len 的读取修复 UAF;只有当 UNIX 套接字的接收队列中的 SKB 可以增长时（这种情况不再发生），检查 tail->len 才有意义。Kuniyuki 解释道：> 提交 869e7c62486e 时（net：af_unix：实现流 sendpage >支持）添加了 sendpage（） 支持，数据可被附加到接收方队列中的最后一个> skb。> > 这就是为什么我们在 unix_stream_data_wait（） 中等待新数据时，需要检查最后一个 skb 的长度是否>更改。> > 但是，提交 a0dbf5f818f9（af_unix：支持 MSG_SPLICE_PAGES）并>提交 57d44a354a43（unix：将 unix_stream_sendpage（） 转换为使用 > MSG_SPLICE_PAGES） 重构的 sendmsg（），现在数据始终>添加到新的 skb。这表示此补丁之前不适用于内核。 6.5（CVE-2026-64109）

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

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

  - ProFTPD mod_sftp包含基于堆的缓冲区溢出，经认证的 SFTP 用户可访问该溢出。fxp_packet_read（） 函数接受攻击者提供的 32 位 big-endian SFTP 数据包长度，而无需进行最低健全性检查。值为 0 会导致读取路径中其他位置的无符号减法下溢至大约 4 GB。该超大请求到达核心内存分配器，该分配器以 size_t 计算舍入大小，但以 32 位 int 的形式传递给 new_block（）;0x100000000的低 32 位为 0，因此当调用程序被告知其收到 ~4 GB 时，new_block（） 会返回一个小（~512 字节）区块。随后的填充循环会将攻击者控制的字节流式传输到 544 字节分配的末尾之后，进而产生攻击者控制的堆缓冲区溢出。经认证的用户可根据需要使用单个畸形 SFTP 数据包（packet_len=0，后跟大于约 544 字节的正文）使每个连接的 ProFTPD 会话子进程崩溃，从而产生可靠的经认证的远程拒绝服务。根据堆布局和相邻分配，虽然提供的概念证明仅证实拒绝服务，但可能会造成堆元数据损坏和拒绝服务以外的其他后果。
    (CVE-2026-53994)

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

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

  - net：bcmgenet：保持 RBUF EEE/PM 禁用 设置RBUF_EEE_EN |一旦 MAC EEE 变为活动状态，RBUF_ENERGY_CTRL中的RBUF_PM_EN会中断 GENET 硬件上的 RX 路径。当链路保持运行且通常的描述符/RX 错误计数器保持静默时，RX 流量停止流动。在该状态下，MAC 仍接受帧（rbuf_ovflow_cnt持续爬升），但 RBUF 不再将其转发到 DMA，因此rx_packets不再在 netdev 级别递增。在某些板上，损坏最终会通过 LPI 退出上的 bcmgenet_rx_poll 以 skb_release_data 中的分页错误告终。在 Pi 4B （BCM2711 + BCM54213PE） 上复制，并由 Florian Fainelli 在具有相同崩溃签名的内部 Broadcom 4908 系列板上确认。
    RBUF_PM_EN未公开记录。由于 phy_support_eee（） 默认启用 EEE，此问题会更频繁地出现，但一旦通过 ethtool 打开 TX LPI，它也会影响较旧的内核，因此它并不特定于最近的更改。始终清晰RBUF_EEE_EN |RBUF_PM_EN bcmgenet_eee_enable_set，因此位在重置期间保持关闭。UMAC 和 TBUF 设置不会受到影响，因此 TX 端的 EEE 可以继续运行。（CVE-2026-64125）

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

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

  - 已修复 Linux 内核中的下列漏洞：nvme: fix bio leak on mapping failure The local bio is always NULL, so we'd leak the bio if the integrity mapping failed. Just get it directly from the request. (CVE-2026-64072)

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

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

  - vsock/vmci：修复对等机在握手期间重置连接时的 UAF vmci_transport_recv_connecting_server（） 在其默认交换机 arm 中为对等机 RST 返回 err = 0：err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ？0：-EINVAL;这会使 vmci_transport_recv_listen（） 跳过 vsock_remove_pending（），将待定套接字留在侦听器的 pending_links 上，sk_state = TCP_CLOSE，而 destroy： 仍然丢弃了在 schedule_delayed_work（） 之前的显式引用。一秒钟后，vsock_pending_work（） 观察到 is_pending=true 并执行完全清除：
    vsock_remove_pending（），然后是两个尾随的 sock_put（sk） 调用 -- 第一个到达 refcount 0 且
    __sk_freed套接字，第二个则写入已释放的对象： 缺陷：KASAN：任务 kworker 在地址 ffff88800b1cac80 处的大小为 4 的 refcount_warn_saturate 写入 slab-after-free 工作队列：事件vsock_pending_work 将对等机 RST 视为任何其他意外数据包类型 （err = -EINVAL）。所有 destroy：arm 现在返回 0 <错误，因此 vmci_transport_recv_listen（） 同步从 pending_links 中删除待定项，vsock_pending_work（） 采用 is_pending=false / ！rejected 分支，仅丢弃自己的工作引用。
    这也结束了 Sashiko 在 v2 上报告的多数据包争用：在任何后续数据包找到它之前，挂起的状态就会从列表中删除。Sashiko 还指出，vmci_transport_recv_listen（） 的 err < 0 路径中预先存在的 sk_acceptq_removed（） 间隙并未由此修补程序引入或改变。使用 KASAN 在 lts-6.12.79 上测试：52/100 未修补 -> 0/100 修补。（CVE-2026-64115）

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

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

  - ntfs3：拒绝对保留$LX的直接用户空间写入 * xattrs NTFS3 使用 $LXUID和 作为 $LXGID$LXMOD$LXDEV内部 WSL 权限元数据，并从 ntfs_get_wsl_perm（） 重新加载到 i_uid、i_gid 和 i_mode中。由于空前缀 xattr 处理程序还允许文件所有者直接在这些名称上调用 setxattr（），可写入的 ntfs3 挂载上的非特权写入器可在自己的文件中植入根所有权和S_ISUID，并在 inode 重新加载后获得 euid 0。拒绝直接用户空间写入保留 $LX的 * 名称。内部 ntfs3 元数据更新保持不变，因为 ntfs_save_wsl_perm（） 直接通过 ntfs_set_ea（） 写入。[almaz.alexandrovich@paragon-software.com：为非特权用户添加了额外的检查]（CVE-2026-63833）

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

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

  - hdlc_ppp：释放 hdlc 状态前同步每个原型的定时器 struct ppp 中嵌入的每个 PPP 控制协议 （LCP/IPCP/IPV6CP） 通过 timer_setup（） 注册一个定时器。该结构 ppp 是 hdlc->state 分配，其 detach_hdlc_protocol（） 在 unregister_hdlc_device（） 和 attach_hdlc_protocol（） 内部的重新附加）两个拆卸路径中使用 kfree（） 释放。ppp proto 从未注册 .detach 回调，因此 detach_hdlc_protocol（） 在 kfree（） 之前未执行任何定时器同步。ppp_cp_event（） 中唯一的取消 timer_delete（&proto->timer） 是部分的（它不等待正在运行的回调）并且仅在 ->CLOSED 转换中运行;ppp_stop（）/ppp_close（） 也不同步。已执行中（在 ppp->lock 上阻断）的 ppp_timer 回调在 kfree 中幸存下来，然后在已释放的内存中取消引用 proto->state / ppp->lock，从而导致释放后使用。通过添加一个在每个原型定时器上调用 timer_shutdown_sync（） 的 .detach 辅助函数来修复此问题。detach_hdlc_protocol（） 在 kfree（hdlc->state） 之前调用 proto->detach（dev），因此 timer_shutdown_sync（） 现在在这两个自由路径中运行。使用 timer_shutdown_sync（） 而不是 timer_delete_sync（），因为 keepalive 路径通过 add_timer（）/mod_timer（） 重新布防定时器，并且 shutdown 会在拆卸期间阻止任何重新激活。附加协议时，初始化 ppp_ioctl（） 中的每个协议定时器，并从 ppp_start（） 删除现在冗余的 timer_setup（），以便在附加时初始化定时器一次，并且 ppp_timer_release（） 从不对未初始化的 timer_list 结构进行操作。attach_hdlc_protocol（） 使用 kmalloc（）（不是 kzalloc），因此 struct ppp 的 protos[i].timer 在第一个 timer_setup（） 之前都是未初始化的垃圾;如果没有此 init-at-attach，则附加 PPP 协议而不启动设备，会使 timer_shutdown_sync（） 在 .detach 中的未初始化内存上运行。将 init 从 ppp_start（）（仅在 NETDEV_UP 上运行）移入附加路径将使初始化无条件，并且避免初始化同一timer_list两次。此缺陷是通过静态分析发现的。（CVE-2026-63803）

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

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

  - fbdev：fbcon：修复 fbcon_do_set_font（） err_out中的越界读取 当 fbcon_do_set_font（） 失败时（例如，由于沉重的内存压力下的 vc_resize（） 内部内存分配失败），它会跳至“err_out”标签以回滚控制台状态。但是，当前回滚逻辑忘记了恢复“hi_font”状态，从而导致严重的状态机损坏。在函数的前面，可调用“set_vc_hi_font（）”来更改“vc->vc_hi_font_mask”并改变屏幕缓冲区。如果“vc_resize（）”随后失败，“err_out”路径将还原“vc_font.charcount”，但完全跳过“vc_hi_font_mask”和屏幕缓冲区的回滚。此不匹配使终端处于非同步状态。
    由于保持设置“vc_hi_font_mask”，VT 子系统仍将接受来自用户空间的大于 255 的字符索引，并将其写入屏幕缓冲区。随后的渲染调用（如“fbcon_putcs（）”）随后将使用这些膨胀的索引来访问恢复的 256 个字符的字体数组，从而导致确定性的越界读取并可能泄露内核内存。通过在错误路径中添加“hi_font”掩码和屏幕缓冲区缺少的回滚逻辑来修复此问题。（CVE-2026-53402）

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

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

  - drm/amdgpu/jpeg：为 JPEG v2.5 环设置no_user_fence JPEG 环不支持 64 位用户屏蔽写入，拒绝有用户屏蔽的 CS 提交。（从提交 3216a7f4e2642bda5fd14f57586e835ae9202587 中精选出的内容）（CVE-2026-63847）

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

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

  - bpf：将 kvfree（） 用于替换的 sysctl 写入缓冲区 proc_sys_call_handler（） 使用 kvzalloc（） 分配其临时 sysctl 缓冲区并将其传递给 __cgroup_bpf_run_filter_sysctl（）。由于 kvzalloc（） 可能会回退到 vmalloc（） 进行大量分配，因此使用 kfree（） 释放该缓冲区是错误的，而且可能损坏内存。使用 kvfree（） 安全地处理 kmalloc 和 kvzalloc（）/vmalloc 分配。我们正在开发的用于内核内存管理缺陷的实验性分析工具在分析 v6.13-rc1 时，首先标记此缺陷。
    该工具仍在开发中，尚未公开可用。手动检查确认 v7.1-rc5 中仍然存在该缺陷。在通过 KASAN 引导并启用 CONFIG_FAILSLAB 引导的 QEMU x86_64 客户机中基于 v7.1-rc4 的错误。为了练习替换路径，测试树还包含随附的针对 __cgroup_bpf_run_filter_sysctl（） 中过时 ret == 1 检查的补丁。复制器将 failslab 注入限制在 proc_sys_call_handler（） 范围内、使用 stacktrace-depth=32 并注入 fail-nth=1，同时从目标 cgroup 中的任务将 8191 字节写入 /proc/sys/kernel/domainname。在该设置下，fail-nth=1 触发了错误：缺陷：无法处理地址的页面错误：ffffeb0200024d48 #PF：
    内核模式下的监督者读取访问权限 #PF： error_code（0x0000） - 不存在页面 PGD 0 P4D 0 哎呀： 哎呀：
    0000 SMP KASAN NOPTI CPU：2 UID：0 PID：209 通信：repro_proc_sys_ 未受感染 7.1.0-rc4-00686-g97625979a5d4 PREEMPT（lazy） 硬件名称：QEMU Standard PC（Q35 + ICH9,2009），BIOS 1.15.0-1 04/01/2014 RIP：0010：kfree+0x6e/0x510 ... 调用跟踪： <TASK> ？
    __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ？
    __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ？srso_return_thunk+0x5/0x5f ？
    __kvmalloc_node_noprof+0x345/0x870 ？proc_sys_call_handler+0x250/0x480 ？srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ？__pfx_proc_sys_call_handler+0x10/0x10 ？srso_return_thunk+0x5/0x5f ？selinux_file_permission+0x39f/0x500 ？srso_return_thunk+0x5/0x5f ？lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ...</TASK> 在相同的测试设置之上应用此补丁时，以 fail-nth=1 重新运行复制程序不会产生相应的 Oops 报告。（CVE-2026-63809）

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

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

  - exfat：修复 exfat_find_dir_entry（） 中潜在的释放后使用 在 exfat_find_dir_entry（） 中，在 fall-through TYPE_EXTEND 分支通过 ep（指向 bh->b_data）读取目录条目之前，通过 brelse（bh） 释放从 exfat_get_dentry（） 获取的buffer_head：brelse（bh）;if （entry_type == TYPE_EXTEND） { ...len = exfat_extract_uni_name（ep， entry_uniname）;... }在 brelse（） 丢弃引用之后，没有任何内容可以保证底层页面支持 bh->b_data 对后续的 exfat_extract_uni_name（） 读取仍然有效。这与提交 fc961522ddbd 中修复的模式相同（exfat：修复 exfat_load_upcase_table（）） 中潜在的释放后使用）。移动 brelse（bh），使其在每个分支上不再取消引用 ep 后运行。在 linux-next 上 CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y 的 QEMU x86_64上确认，使用特制的 exFAT 图像（具有强制TYPE_EXTEND路径的相同哈希冲突的长文件名）。在 brelse（bh） 和 ep 读取之间插入仅限调试的 invalidate_bdev（） 以使陈旧的取消引用窗口具有确定性，未修补的内核将发生错误： 缺陷：KASAN：
    exfat_find_dir_entry+0x133b/0x15a0 中的释放后使用 缺陷：无法处理地址的页面错误：
    ffff88801a5fa0c2 错误：0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP：
    0010：exfat_find_dir_entry+0x1188/0x15a0 应用此修补程序后，同一个经检测的线束可以在相同的审查器堆栈下干净利落地完成。我没有在普通回收下重现未检测内核上的崩溃;检测的 A/B 确立了生命周期违规，并且补丁会关闭它，而不是未经帮助的可触发性声明。（CVE-2026-63808）

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

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

  - drm/amdgpu：分配时零初始化 GART 表。GART TLB 会在取消映射后刷新，但不会在映射后刷新。由于 amdgpu_bo_create_kernel（） 不会对缓冲区进行零初始化，因此当写入单一 PTE 时，TLB 可能会推测性地从同一个高速缓存块加载其他未初始化的条目。这些垃圾条目可能看起来有效，后续写入相同高速缓存块中的另一个 PTE 可能导致 GPU 使用来自 TLB 的过时垃圾 PTE。通过调用 memset_io（） 以在分配后立即使用 gart_pte_flags 对 GART 表进行零初始化来修复此问题。使用基于 SDMA 的清除AMDGPU_GEM_CREATE_VRAM_CLEARED将无法工作，因为 SDMA 需要初始化 GART 才能工作。（从提交 d9af8263b82b6eaa60c5718e0c6631c5037e4b24 中精选出的内容）（CVE-2026-53374）

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

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

  - net：airoha：在 airoha_qdma_cleanup_tx_queue（） 中添加缺失位 与 airoha_qdma_cleanup_rx_queue（） 类似，重置airoha_qdma_cleanup_tx_queue例程中的 DMA TX 描述符。此外，重置TX_DMA_IDX TX_CPU_IDX以通知 NIC QDMA TX 环为空。（CVE-2026-63859）

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

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

  - NFSv4/pNFS：拒绝 nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr（） 中的零长度r_addr解码 GETDEVICEINFO multipath-DS 正文中 netaddr4 的r_netid和r_addr opaques，然后立即调用 strrchr（buf， '.'） 以定位端口分隔符。两种解码都使用 xdr_stream_decode_string_dup（），当前代码在取消引用返回的字符串之前仅检查 nlen < 0 / rlen < 0。当线上不透明的长度为零时，xdr_stream_decode_opaque_inline（） 返回 0，xdr_stream_decode_string_dup（） 落到其 *str = NULL;返回 ret 尾部，保留 buf NULL，返回值为 0。< 0 检查未捕获此错误，下一行是 strrchr（NULL， '.'），这是可从挂载到恶意或遭到破坏的元数据服务器的任何 pNFS-flexfile 客户端访问的内核空指针取消引用。明确拒绝零长度状况，以便解码器因 -EBADMSG（被视为畸形 GETDEVICEINFO 正文）而失败，而不是使客户端发生错误。（CVE-2026-53391）

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

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

  - drm/amdgpu/vcn：设置 VCN v3.0 enc/dec 环的no_user_fence VCN 编码器和解码器环不支持 64 位用户隔离写入，拒绝带有用户隔离的 CS 提交。（从提交 663bed3c7b8b9a7624b0d95d300ddae034ad0614 中精选出的内容）（CVE-2026-63854）

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

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

  - block：避免在用户空间中挂载 bdev 伪文件系统 bdev 伪文件系统是用户空间不应干预的内部内核文件系统。取消注册，这样用户空间甚至无法尝试挂载它。这修复了尝试访问文件时发生的缺陷 [1]，原因是系统调用 move_mount（） 使用在 inode_operations 结构中声明的指针，对于 bdev 伪文件系统而言，该指针始终等于 0。'inode->i_op = &empty_iops;' [1] 缺陷：内核空指针取消引用，地址：0000000000000000 #PF：内核模式下的监督程序指令提取 #PF：error_code（0x0010） - 不存在页面 PGD 23380067 P4D 23380067 PUD 23381067 PMD 0 错误：0010 [#1] PREEMPT SMP KASAN NOPTI CPU：2 PID：17125 Comm：syz-executor.0 未受感染 6.1.155-syzkaller-00350-g84221fde2681 #0 硬件名称：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS 1.12.0-1 04/01/2014 RIP： 0010：0x0 调用跟踪： <TASK> lookup_open.isra.0+0x700/0x1180 fs/namei.c：3460 open_last_lookups fs/namei.c：3550 [内联] path_openat+0x953/0x2700 fs/namei.c：3780 do_filp_open+0x1c5/0x410 fs/namei.c：3810 do_sys_openat2+0x171/0x4d0 fs/open.c：1318 do_sys_open fs/open.c：1334 [内联] __do_sys_openatfs/open.c：1350 [内联] __se_sys_openat fs/open.c：1345 [内联] __x64_sys_openat+0x13c/0x1f0 fs/open.c：1345 do_syscall_x64 arch/x86/entry/common.c：51 [内联] do_syscall_64+0x35/0x80 arch/x86/entry/common.c：81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 由 Linux 验证中心 （linuxtesting.org） 通过 syzkaller 发现。（CVE-2026-63810）

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

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

  - media：i2c：ov8856：释放 ov8856_init_controls（） 中出错时的控件处理程序 如果添加控件失败，则未释放控制处理程序，请添加错误退出标签并转换现有错误返回以使用它。
    (CVE-2026-53379)

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

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

  - KEYS：修复 keyctl_pkey_params_get_2（） 中的溢出 未正确计算内部输出缓冲区的长度，如果提供的缓冲区太小，则可导致溢出。通过使用加密基元的最大长度大小分配内部输出而非调用程序提供的大小，来修复缺陷。（CVE-2026-63824）

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

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

  - f2fs：原子写入期间使用原始 inode 读取 COW 数据 更新原子写入文件时，f2fs_write_begin（） 可能会从 COW inode 读取回以前写入的数据：
    prepare_atomic_write_begin（） 在 COW inode 中找到块并设置use_cow，然后使用 COW inode 构建读取 bio：f2fs_submit_page_read（use_cow ？F2FS_I（inode）->cow_inode：inode 等）;而 f2fs_grab_read_bio（） 则决定是否通过 fscrypt_inode_uses_fs_layer_crypto（） 决定是否基于该 inode 的 bio 计划 fs-layer 解密 （STEP_DECRYPT）。但是，被填充的 folio 属于原始 inode （folio->mapping->host == inode），并且存储在 COW 块中的数据使用原始 inode 的上下文（而不是 COW inode）进行加密（或保留为明文） -- 请参阅 f2fs_encrypt_one_page（），后者会键出 fio->page->mapping->host）。fscrypt_decrypt_pagecache_blocks（） 同样在 folio->mapping->host 上操作。COW inode 在父目录中创建为 tmpfile，并从那里继承其加密策略。通过test_dummy_encryption新创建的 COW inode 将获得虚拟策略并被加密，而预先存在的常规文件（在应用策略之前创建，例如
    已存在于磁盘上的映像中 -- 保持未加密。读取路径随后根据加密的 COW inode 设置 STEP_DECRYPT，并在主机（未加密的原始 inode）具有 NULL ->i_crypt_info 的 folio 上调用 fscrypt_decrypt_pagecache_blocks（），对其进行取消引用： 哎呀：一般保护错误，可能针对非规范地址... KASAN：范围 [0x0000000000000008-0x000000000000000f] 中的 null-ptr-deref RIP：0010：fscrypt_decrypt_pagecache_blocks+0xa0/0x310 工作队列：
    f2fs_post_read_wq f2fs_post_read_work 调用跟踪：fscrypt_decrypt_bio+0x1eb/0x340 f2fs_post_read_work+0xba/0x140 process_one_work+0x91c/0x1a40 worker_thread+0x677/0xe90 kthread+0x2bc/0x3a0 仅需要 COW inode 即可定位磁盘上的区块，且该区块地址已由 prepare_atomic_write_begin（） 通过 __find_data_block（cow_inode 解析为 @blkaddr， ...);然后，f2fs_submit_page_read（） 直接从该物理@blkaddr中读取，因此 inode 参数仅选择读取后的 crypto 上下文，而不选择获取的块。因此，使用 @inode 读取会返回相同（最新的、尚未提交的）COW 数据，同时使 fs 层解密决策和内联加密路径使用正确的（原始 inode 的）密钥。由于读取站点不再使用 COW inode，则 use_cow 标记没有剩余使用者;从 f2fs_write_begin（） 和 prepare_atomic_write_begin（） 中删除它。（CVE-2026-63811）

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

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

  - NFSv4/flexfiles：拒绝零 filehandle 版本计数 ff_layout_alloc_lseg（） 从 flexfiles 布局正文解码 filehandle-version 数组计数。该值用作 kzalloc_objs（） 的计数，当前代码仅拒绝 NULL。零计数产生ZERO_SIZE_PTR，即使后续的 flexfiles 路径假设至少存在一个 filehandle 版本，仍可将其存储在 dss_info->fh_versions 中。分配前拒绝 fh_count == 0，从而匹配 flexfiles GETDEVICEINFO 解析器中现有的零version_count验证。QEMU/KASAN 运行畸形 flexfiles 布局命中： KASAN：范围内的 null-ptr-deref [0x0000000000000010-0x0000000000000017] RIP：
    0010：ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 内核错误 - 不同步：致命异常 经过修补的内核拒绝不存在 KASAN/oops/panic 的畸形布局，有效的 fh_count=1 回归仍可以干净地打开、读取和卸载。（CVE-2026-53392）

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

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

  - drm/amdgpu/vcn：设置 VCN v2.0 enc/dec 环的no_user_fence VCN 编码器和解码器环不支持 64 位用户隔离写入，拒绝有用户隔离的 CS 提交。（从提交 e2b5499fca55f1a32960a311bbb62e35891eaf73 中精选出的内容）（CVE-2026-63856）

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

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

  - f2fs：修复以对 fs/f2fs/file.c：845！ 的 f2fs_get_node_folio_ra（） 内核缺陷进行健全性检查！哎呀：无效操作码：0000 [#1] SMP KASAN NOPTI CPU：0 UID：0 PID：5336 通信：syz.0.0 未受感染的 syzkaller #0 PREEMPT（完整） 硬件名称：QEMU 标准 PC（Q35 + ICH9,2009），BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP：0010：f2fs_do_truncate_blocks+0x1115/0x1140 fs/f2fs/file.c：845 代码：fc fc 90 0f 0b e8 8b 9d 9a fd 90 0f 0b e8 83 9d 9a fd 48 89 df 48 c7 c6 60 d1 1a 8c e8 54 f1FC FC 90 0f 0b e8 6c 9d 9a fd 90 <0f> 0b e8 64 9d 9a fd 90 0f 0b 90 e9 93 fd ff ff e8 56 9d 9a fd 90 RSP： 0018：ffffc9000e4474c0 EFLAGS： 00010283 RAX：
    ffffffff842b1d34 RBX： 0000000000000003 RCX： 0000000000100000 RDX： ffffc9000f03a000 RSI： 0000000000035503 RDI： 0000000000035504 RBP： ffffc9000e447608 R08： ffff8880123b0000 R09： 0000000000000002 R10：
    00000000fffffffe R11： 0000000000000002 R12： 0000000000000001 R13： 000000000000000 R14： 1ffff92001c88ea0 R15： 00000000ffff039c FS： 00007f7e02ee36c0（0000） GS：ffff88808c887000（0000） knlGS：0000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：00007ff0305c4000 CR3：0000000012d4c000 CR4：0000000000352ef0 调用跟踪： <TASK> f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c：882 f2fs_truncate+0x471/0x7c0 fs/f2fs/file.c：940 f2fs_evict_inode+0xa3f/0x1ac0 fs/f2fs/inode.node.（inode.） c：907 evict+0x61e/0xb10 fs/inode.c：841 f2fs_fill_super+0x5f43/0x78f0 fs/f2fs/super.c：5224 get_tree_bdev_flags+0x431/0x4f0 fs/super.c：1694 vfs_get_tree+0x92/0x2a0 fs/super.c：1754 fc_mount fs/namespace.c：1193 [内联] do_new_mount_fc fs/namespace.c：3758 [内联] do_new_mount+0x341/0xd30 fs/namespace.c：3834 do_mount fs/namespace.c：4167 [内联] __do_sys_mount fs/namespace.c：4383 [内联] __se_sys_mount+0x31d/0x420 fs/namespace.c：4360 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [内联] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f count = ADDRS_PER_PAGE（dn.node_folio， inode）;计数 -= dn.ofs_in_node;f2fs_bug_on（sbi，计数 < 0）;模糊测试将在 f2fs 中触发上述bug_on。根本原因是：在损坏的 inode 中，有一个直接节点在其页脚中具有相同的 ino 和 nid，因此在 f2fs_do_truncate_blocks（） 中，当 f2fs_get_dnode_of_data（） 找到此类 dnode： 1） ADDRS_PER_PAGE（dn.node_folio， inode） 将返回 923 2） 一旦 dn.ofs_in_node 指向 addr[923， 1017] 然后它将触发系统错误。让我们介绍NODE_TYPE_NON_IXNODE来指示当前节点不应该是 inode 或 xattr 节点，然后在以下路径中使用它来检测 inode 映射表中不一致的节点链：- f2fs_do_truncate_blocks - f2fs_get_dnode_of_data - f2fs_get_node_folio_ra - __get_node_folio - f2fs_sanity_check_node_footer - 大小写NODE_TYPE_NON_IXNODE ->检查是否是 inode|xnode （CVE-2026-63819）

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

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

  - f2fs：验证 f2fs_acl_from_disk（） 中的 ACL 条目大小 f2fs_acl_count（） 仅验证聚合 ACL xattr 长度。畸形 ACL 仍可将ACL_USER或ACL_GROUP放在仅包含 struct f2fs_acl_entry_short 字节的插槽中，然后 f2fs_acl_from_disk（） 在验证完整条目是否适合之前读取条目>e_id。在阅读e_tag和e_perm之前需要一个简短的条目，在读取ACL_USER和ACL_GROUP的e_id之前要求一个完整的条目。从这些新的截断条目检查返回 -EFSCORRUPTED，同时保持预先存在的 -EINVAL 路径不变。验证重现了此内核报告： KASAN __f2fs_get_acl+0x6fb/0x7e0 中的越界 RIP： 0033：0x7f4b835ea7aa 有缺陷的地址属于 ffff888114589960 中的对象，该对象属于大小为 8 的缓存 kmalloc-8 有缺陷的地址位于分配的 8 字节区域右侧 0 字节处 [ffff888114589960、ffff888114589968） 读取大小为 4 调用跟踪：
    dump_stack_lvl+0x66/0xa0 （？：？） print_report+0xce/0x630 （？：？） __f2fs_get_acl+0x6fb/0x7e0 （fs/f2fs/acl.c：169） srso_alias_return_thunk+0x5/0xfbef5 （？：？） __virt_addr_valid+0x224/0x430 （？：？） kasan_report+0xe0/0x110 （？：？） __f2fs_get_acl+0x5/0x7e0 （fs/f2fs/acl.c：169） __get_acl+0x281/0x380 （？：？） vfs_get_acl+0x10b/0x190 （？：？） do_get_acl+0x2a/0x410 （？：?)do_get_acl+0x9/0x410 （？：？） do_getxattr+0xe8/0x260 （？：？） filename_getxattr+0xd1/0x140 （？：？） do_getname+0x2d/0x2d0 （？：？） path_getxattrat+0x16c/0x200 （？：？） lock_release+0xc8/0x290 （？：？） cgroup_update_frozen+0x9d/0x320 （？：？） lockdep_hardirqs_on_prepare+0xea/0x1a0 （？：？） trace_hardirqs_on+0x1a/0x170 （？：？）
    _raw_spin_unlock_irq+0x28/0x50 （？：？） do_syscall_64+0x115/0x6a0 （arch/x86/entry/syscall_64.c：87） entry_SYSCALL_64_after_hwframe+0x77/0x7f （？：？）（CVE-2026-63814）

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

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

  - serial： 8250_dw：如果 clk_notifier_register（） 失败则取消注册 8250 端口 dw8250_probe（） 通过 serial8250_register_8250_port（） 注册 8250 端口，然后在设备具有时钟时注册时钟通知程序。
    如果 clk_notifier_register（） 失败，探测返回错误，但会使 8250 端口保持注册状态。匹配的 serial8250_unregister_port（） 位于探测失败时不会调用的 dw8250_remove（） 中，因此端口插槽会一直处于被占用状态，直至设备恢复或系统重新启动为止。当端口仍在引用 devm 分配的驱动程序数据时会释放该数据（通过保存的private_data和 serial_in/serial_out 回调），因此在重新绑定之前对该端口槽的任何访问都存在释放后使用危险。注销 clk_notifier_register（） 错误路径上的端口。（CVE-2026-53384）

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

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

  - drm/amdgpu/jpeg：为 JPEG v2.0 环设置no_user_fence JPEG 环不支持 64 位用户屏蔽写入，拒绝带有用户屏蔽的 CS 提交。（从提交 96179da0c6b059eb31706a0abe8dd6381c533143 中精选出的内容）（CVE-2026-63848）

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

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

  - drm/amdgpu/jpeg：为 JPEG v4.0 环设置no_user_fence JPEG 环不支持 64 位用户隔离写入，拒绝有用户隔离的 CS 提交。（从提交 8d0cac9478a3f046279c657d6a2545de49ae675a 中精选出的内容）（CVE-2026-63845）

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

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

  - drm/amdgpu/vcn：设置 VCN v4.0 enc 环的no_user_fence VCN 编码器和解码器环不支持 64 位用户隔离写入，拒绝有用户隔离的 CS 提交。（从提交 fd852c048b46f9825e904a4f3f4538fe9d8827d9 中精选出的内容）（CVE-2026-63853）

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

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

  - apparmor：调解 TCP fast open sendmsg sendmsg（）/sendto（） 的隐式连接，MSG_FASTOPEN 是 connect（2） 和 write（2） 的组合：它在 SYN 中打开连接。apparmor_socket_sendmsg（） 仅检查AA_MAY_SEND，因此授权发送但拒绝连接的配置文件可让受限任务打开 connect（2） 会拒绝的出站 TCP/MPTCP 连接， 绕过 CONNECT 中介。设置MSG_FASTOPEN并提供目标时调解隐式连接。将其添加到 apparmor_socket_sendmsg（）（不是 recvmsg 也使用的共享 aa_sock_msg_perm（） 辅助函数），然后直接调用 aa_sk_perm（），以镜像 selinux 和 tomoyo 补丁。sk_is_tcp（） 不包括 MPTCP fast open，因此 SOCK_STREAM/IPPROTO_MPTCP arm 是明确的。（CVE-2026-63828）

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

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

  - f2fs： atomic：修复 f2fs_inode_info.atomic_inode 上的 UAF 问题 - ioctl（F2FS_IOC_GARBAGE_COLLECT_RANGE） - shrink - f2fs_gc - gc_data_segment - ra_data_block（cow_inode） - mapping = F2FS_I（inode）->atomic_inode->i_mapping ： f2fs_is_cow_file（cow_inode） 为 true - f2fs_evict_inode（atomic_inode） - clear_inode_flag（fi->cow_inode， FI_COW_FILE） - F2FS_I（fi->cow_inode）->atomic_inode = NULL ... - truncate_inode_pages_final（atomic_inode） - f2fs_grab_cache_folio（mapping） ：在 atomic_inode->mapping 中创建 folio - clear_inode（atomic_inode） - BUG_ON（atomic_inode->i_data.nrpages） 我们需要在垃圾回收期间使用 fi->atomic_inode 的映射字段之前添加引用，否则将导致 UAF 问题。（CVE-2026-63816）

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

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

  - NFSD：修复解码错误清理SECINFO_NO_NAME nfsd4_decode_secinfo_no_name（） 目前在解码sin_style后初始化 sin_exp。如果 XDR 流被截断，解码器会在初始化 sin_exp 之前返回 nfserr_bad_xdr。由于提交了 3fdc54646234（NFSD：减少需要清除的 struct nfsd4_compoundargs数量），则在 RPC 调用之间未清除内联 iops 数组。因此，SECINFO_NO_NAME解码失败可使sin_exp保留之前操作过时的 union 内容。
    错误响应路径仍在调用 nfsd4_secinfo_no_name_release（），其会在非 NULL sin_exp上调用 exp_put（）。在第一个可失败的解码步骤之前初始化 sin_exp，与 nfsd4_decode_secinfo（） 相匹配。
    (CVE-2026-53398)

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

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

  - wifi：ath11k：修复取消绑定时的警告 如果在某些初始化期间出现与固件相关的错误，则会释放缓冲区 dp->tx_ring[i].tx_status。但是，当设备未绑定 （ath11k_pci） 时，系统会再次释放此信息，并得到：警告：CPU：0 PID：6231 at mm/slub.c：4368 free_large_kmalloc+0x57/0x90 调用跟踪：free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... 由于 MSI 寻址初始化失败，因此一律可从 VM 重现此问题。要修复该问题，只需在释放之后将缓冲区设置为空以避免双重释放。（CVE-2026-63822）

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

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

  - f2fs：non-inline-xattr inode 的绑定i_inline_xattr_size 启用flexible_inline_xattr功能时，do_read_inode（） 会无条件加载磁盘上的i_inline_xattr_size：if （f2fs_sb_has_flexible_inline_xattr（sbi）） fi->i_inline_xattr_size = le16_to_cpu（ri->i_inline_xattr_size）;
    但 sanity_check_inode（） 仅当 inode 也设置了 FI_INLINE_XATTR 标记时才对其进行范围检查。携带内联目录项或内联数据但不FI_INLINE_XATTR（内联目录的正常布局）的 inode 因此会从构建的图像中保留完全受攻击者控制的i_inline_xattr_size。
    get_inline_xattr_addrs（） 返回该值时没有标记门控，因此它馈送 inode 几何体：
    MAX_INLINE_DATA（） = 4 * （CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1） NR_INLINE_DENTRY（） = MAX_INLINE_DATA（） * BITS_PER_BYTE / （...） addrs_per_page（） = CUR_ADDRS_PER_INODE - i_inline_xattr_size 大型i_inline_xattr_size会将 MAX_INLINE_DATA（） 和 NR_INLINE_DENTRY（） 设置为负值，因此 make_dentry_ptr_inline（） 将 d->max （int） 设置为负值。然后，内联目录遍历将无符号长bit_pos与负 d->max 进行比较，后者被提升为巨大的无符号边界，并且读取范围远远超出内联区域：while （bit_pos < d->max） /* fs/f2fs/dir.c */ ...test_bit_le（bit_pos， d->bitmap） / d->dentry[bit_pos] ... 挂载构建的镜像并读取此类目录会在 f2fs_fill_dentries（） 中触发越界读取;同样的下溢也会损坏常规文件的 ADDRS_PER_INODE。只要启用 flexible_inline_xattr 功能（即，每当从磁盘加载值并消耗该值时），就针对 MAX_INLINE_XATTR_SIZE 验证i_inline_xattr_size，并在实际携带内联 xattr 的 inode 上保持下MIN_INLINE_XATTR_SIZE限边界，以便仍接受 i_inline_xattr_size == 0 的合法 inode。（CVE-2026-63815）

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

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

  - irqchip/imgpdc：修复资源泄漏，添加删除时缺少的链式处理程序清理 驱动程序在探测期间使用 irq_alloc_domain_generic_chips（） 分配域泛型芯片，并使用 irq_set_chained_handler_and_data（） 设置链式处理程序。但是，删除驱动程序时，不会释放通用芯片，且不会删除链接的处理程序。通用芯片仍保留在全局gc_list上，随后可能在删除驱动程序后被通用中断芯片暂停、恢复或关机回调访问，从而可能导致释放后使用和内核崩溃。probe for peripheral 和 syswake 中断中安装的链式处理程序也悬摆，这可导致虚假中断访问已释放的内存。通过以下方法修复这些问题：- 在 domain->flags 中设置 IRQ_DOMAIN_FLAG_DESTROY_GC 标记，以便在调用 irq_domain_remove（） 时核心代码自动删除通用芯片
    - 清除 pdc_intc_remove（） （）CVE-2026-63798 中所有含有 NULL 的链式处理程序

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

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

  - wifi：mt76：在 mt76_sta_add 中添加 wcid 发布检查 由于 mt7925_mac_sta_add 发布 wcid，因此在mt76_sta_add中添加发布检查以避免重新初始化 wcid->poll_list。使用 mt7925 和 7.1-rc4 时发现 dev->sta_poll_list 损坏。根据损坏信息，prev->next 更改为自身。
    wlan0：断开从 AP 90：fb：5d：94：8b：e3 与 90：fb：5d：94：8b：e2 的新认证的连接 wlan0：使用 90：fb：5d：94：8b：e2 （本地地址=84：9e：56：9c：7e：6b） wlan0：将认证发送到 90：fb：5d：94：8b：e2（尝试 1/3）slab kmalloc-8k 启动 ffff8c80958a6000 指针偏移 4160 大小 8192 list_add损坏。prev->next 应该是 next （ffff8c808a7488f8），但以前是 ffff8c80958a7040。（prev=ffff8c80958a7040）. mt76_wcid_add_poll+0x95/0xd0 [mt76] mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common] mt7925_rx_check+0xa7/0xc0 [mt7925_common] mt76_dma_rx_poll+0x50d/0x790 [mt76] mt792x_poll_rx+0x52/0xe0 [mt792x_lib] （CVE-2026-63832）

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

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

  - nfsd：在 setlease 失败时释放布局 stid nfs4_alloc_stid（） 通过 cl_lock 下的 idr_alloc_cyclic（） 将新的 stid 发布到 cl->cl_stateids，然后再返回到 nfsd4_alloc_layout_stateid（）。
    随后 nfsd4_layout_setlease（） 失败时，错误路径会直接使用 kmem_cache_free（） 释放布局 stateid，而不调用 idr_remove（），这样会使 IDR 插槽指向已释放的 slab 内存。
    任何后续的 IDR 遍历器（states_show，客户端拆卸）都会取消引用悬摆指针。IDR 发布的 stid 的正确拆卸方式为 nfs4_put_stid（），它会删除 cl_lock 下的 IDR 插槽，将 sc_free （nfsd4_free_layout_stateid） 分派至通过 nfsd4_close_layout（） 发布 ls->ls_file，并丢弃其末尾的 nfs4_file 引用。第二个问题阻断了切换：nfsd4_free_layout_stateid（） 会无条件地通过 ls_lock 下的 delayed_work_pending（） 检查 ls->ls_fence_work，但 INIT_DELAYED_WORK（&ls->ls_fence_work， ...） 目前仅在 setlease 调用之后运行。在 setlease-failure 路径中，析构函数会接触到未初始化的delayed_work。nfsd4_alloc_layout_stateid（） nfs4_alloc_stid（） /* cl_lock 下的idr_alloc_cyclic */ nfsd4_layout_setlease（） /* 失败 */ nfs4_put_stid（） nfsd4_free_layout_stateid（） delayed_work_pending（&ls->ls_fence_work） /* 需要 INIT */ nfsd4_close_layout（） /* nfsd_file_put（ls->ls_file） */ put_nfs4_file（） 通过将 ls_fenced / ls_fence_delay / INIT_DELAYED_WORK初始化提升到 nfsd4_layout_setlease（） 调用上方进行修复， 并将手动 nfsd_file_put + put_nfs4_file + kmem_cache_free 清理替换为单个 nfs4_put_stid（stp）。（CVE-2026-53399）

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

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

  - drm/msm：始终恢复 gpu 以前，如果没有其他工作可做，恢复工作线程不会触发恢复，而是依赖 gpu 进入睡眠状态，然后在提交更多工作时恢复。Recover_worker将首先增加悬挂环的围栏，因此，如果只有一项作业提交到环并且导致挂起，它将提前退出。无法保证在提交更多工作之前 gpu 会挂起和恢复，如果 gpu 处于挂起状态，它将保持该状态并可能再次触发超时。只需停止检查并始终恢复 gpu。Patchwork：
    https://patchwork.freedesktop.org/patch/704066/ (CVE-2026-53377)

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

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

  - mac802154：llsec：在就地 crypto llsec_do_encrypt_unauth（）、llsec_do_encrypt_auth（）、llsec_do_decrypt_unauth（） 和 llsec_do_decrypt_auth（） 之前添加 skb_cow_data（），均对 skb 数据执行就地加密转换。他们构建一个包含指向 skb 线性数据区的 sg_init_one（） 的 scatterlist，然后将与 src 和 dst 相同的 scatterlist 传递到 crypto API（例如
    crypto_skcipher_encrypt/decrypt、crypto_aead_encrypt/decrypt）。在 RX 路径上，
    __ieee802154_rx_handle_packet（） 克隆收到的 skb，然后通过 ieee802154_subif_frame（） 将其传递给每个订阅者。克隆的 skb 通过引用计数共享相同的底层数据缓冲区。
    当 llsec_do_decrypt（） 随后在适当的位置修改此共享缓冲区时，它会损坏其他克隆（可能属于其他套接字或子系统）仍然引用的数据。在 TX 路径中，当 skb 的头部被克隆时（skb_cloned（） 返回 true），可能会发生类似的数据共享。修复方法是在执行任何就地 crypto 操作之前调用 skb_cow_data（）。skb_cow_data（） 确保 skb 的数据区域不会被共享：如果 skb 头被克隆或数据跨越多个片段，它会将数据复制到可以在适当的位置安全修改的私有缓冲区中。这与以下模式使用的模式相同：- ESP（net/ipv4/esp4.c、net/ipv6/esp6.c） - MACsec （drivers/net/macsec.c） - WireGuard （drivers/net/wireguard/receive.c） - TIPC （net/tipc/crypto.c） 如果没有此保护，共享 skb 数据上的就地加密会导致：- 其他 skb 克隆的静默数据损坏 - 当 crypto API scatterwalk 写入已由另一个克隆的 kfree_skb（） 释放的页面时的释放后使用 - 并发 802.15.4 下内核崩溃启用安全性的流量（KASAN/KMSAN 报告释放后使用 slab-use-free）由 0sec （https://0sec.ai） 使用自动化源分析发现。（CVE-2026-63831）

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

ID	名称	严重性
327921	Linux Distros 未修补的漏洞：CVE-2026-64026	high
327920	Linux Distros 未修补的漏洞：CVE-2026-64006	high
327919	Linux Distros 未修补的漏洞：CVE-2026-63947	high
327918	Linux Distros 未修补的漏洞：CVE-2026-63895	high
327917	Linux Distros 未修补的漏洞：CVE-2026-64163	medium
327916	Linux Distros 未修补的漏洞：CVE-2026-64077	high
327915	Linux Distros 未修补的漏洞：CVE-2026-64078	high
327914	Linux Distros 未修补的漏洞：CVE-2026-64070	medium
327913	Linux Distros 未修补的漏洞：CVE-2026-63970	high
327912	Linux Distros 未修补的漏洞：CVE-2026-64112	high
327911	Linux Distros 未修补的漏洞：CVE-2026-64066	critical
327910	Linux Distros 未修补的漏洞：CVE-2026-64017	high
327909	Linux Distros 未修补的漏洞：CVE-2026-64160	critical
327908	Linux Distros 未修补的漏洞：CVE-2026-64109	high
327905	Linux Distros 未修补的漏洞：CVE-2026-53994	high
327904	Linux Distros 未修补的漏洞：CVE-2026-64125	critical
327903	Linux Distros 未修补的漏洞：CVE-2026-64072	medium
327902	Linux Distros 未修补的漏洞：CVE-2026-64115	high
327894	Linux Distros 未修补的漏洞：CVE-2026-63833	high
327893	Linux Distros 未修补的漏洞：CVE-2026-63803	high
327892	Linux Distros 未修补的漏洞：CVE-2026-53402	high
327891	Linux Distros 未修补的漏洞：CVE-2026-63847	high
327890	Linux Distros 未修补的漏洞：CVE-2026-63809	high
327889	Linux Distros 未修补的漏洞：CVE-2026-63808	critical
327888	Linux Distros 未修补的漏洞：CVE-2026-53374	high
327887	Linux Distros 未修补的漏洞：CVE-2026-63859	high
327886	Linux Distros 未修补的漏洞：CVE-2026-53391	high
327885	Linux Distros 未修补的漏洞：CVE-2026-63854	high
327884	Linux Distros 未修补的漏洞：CVE-2026-63810	high
327883	Linux Distros 未修补的漏洞：CVE-2026-53379	medium
327882	Linux Distros 未修补的漏洞：CVE-2026-63824	high
327881	Linux Distros 未修补的漏洞：CVE-2026-63811	medium
327880	Linux Distros 未修补的漏洞：CVE-2026-53392	high
327879	Linux Distros 未修补的漏洞：CVE-2026-63856	high
327878	Linux Distros 未修补的漏洞：CVE-2026-63819	high
327877	Linux Distros 未修补的漏洞：CVE-2026-63814	high
327876	Linux Distros 未修补的漏洞：CVE-2026-53384	critical
327875	Linux Distros 未修补的漏洞：CVE-2026-63848	high
327874	Linux Distros 未修补的漏洞：CVE-2026-63845	high
327873	Linux Distros 未修补的漏洞：CVE-2026-63853	high
327872	Linux Distros 未修补的漏洞：CVE-2026-63828	high
327871	Linux Distros 未修补的漏洞：CVE-2026-63816	high
327870	Linux Distros 未修补的漏洞：CVE-2026-53398	critical
327869	Linux Distros 未修补的漏洞：CVE-2026-63822	high
327868	Linux Distros 未修补的漏洞：CVE-2026-63815	high
327867	Linux Distros 未修补的漏洞：CVE-2026-63798	medium
327866	Linux Distros 未修补的漏洞：CVE-2026-63832	high
327865	Linux Distros 未修补的漏洞：CVE-2026-53399	critical
327864	Linux Distros 未修补的漏洞：CVE-2026-53377	medium
327863	Linux Distros 未修补的漏洞：CVE-2026-63831	high

检测

Nessus 的 Misc. 系列

high

high

high

high

medium

high

high

medium

high

high

critical

high

critical

high

high

critical

medium

high

high

high

high

high

high

critical

high

high

high

high

high

medium

high

medium

high

high

high

high

critical

high

high

high

high

high

critical

high

high

medium

high

critical

medium

high