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

  - btrfs：数据回写提交期间的写保护 Folio 095be159f3eb（btrfs：统一 Folio 脏标记清除） 将 extent_write_cache_pages（） 中的 folio_clear_dirty_for_io（） 调用替换为普通 folio_test_dirty（） 检查。除了清除脏标记外，folio_clear_dirty_for_io（） 还会调用 folio_mkclean（），对映射 folio 的共享 mmap PTE 进行写保护。请注意，稍后在 submit_one_sector（） 中，当我们在作品集的最后一个扇区（非子页面情况的唯一扇区）上清除脏时，仍然会调用 folio_clear_dirty_for_io（）。但我们在 extent_write_cache_pages（） 中失去了这个早期的电话。
    如果没有额外的写保护，使用 mmap-ed 文件的进程可在回写使用扇区时修改扇区，其期望得到稳定的 folio（校验和、压缩、复制等）而不发生错误，表现为一些具体的缺陷。1. 对于大型对开本或子页面扇区大小，可以提交不涵盖整个对开本的简历。当这种情况发生时，我们将有一个我们 *不* 调用 folio_clear_dirty_for_io（） 的对开本的简历。如果具有现有 mmap-ed PTE 的任务在此窗口中写入（没有错误..），则可导致损坏。如果写入在校验和或写入本身正在进行时到达，这可导致无效的校验和，并且稍后会在读取时造成损坏报告。如果写入是在校验和/写入完成后，但在清除最后一个脏扇区之前到达的，则写入存在于页面缓存中，但不会影响脏跟踪，并且将在完全完成提交作品集并清除脏位时丢失。这会导致即使调用 fsync（） 也会丢失写入。2. 对于与主 extent_writepage（） 循环分批完成的分区提交，我们还存在这些提交违反 csum 的风险。分区写入被限制在max_zone_append_size上并且与作品集不对齐，因此提交可以跨越两个作品集。在 extent_write_cache_pages（） 中处理的第一个作品集将调用 extent_write_locked_range（），后者将提交下一个作品集的部分范围，而该作品集的其余部分仍可能是脏的。因此，清除提交的扇区脏不会调用 folio_clear_dirty_for_io（），我们遇到同样的问题。由于 extent_write_cache_pages（） 会跳过这些批量提交的作品集（它们已被前面的作品集标记为从提交中进行回写），因此我们必须在 lock_delalloc_folios（） 中添加额外的写保护。3. 对于内联盘区，这将微妙地存在丢失写入的风险，这些写入发生在我们复制内联盘区之后/期间，但在我们清除作品集上的脏盘区之前。4.
    对于跨 EOF 的作品集，mmap 可篡改过去 EOF 的归零字节，并造成在未来的错误无法正确看到它们而非零的情况下保留这些字节。5. 最后，对于压缩盘区，我们在压缩作品集时冒着修改作品集的风险，这将导致压缩数据损坏。具体来说，在 run_delalloc_compressed（） 中，我们将工作排队以在 BTRFS_COMPRESSION_CHUNK_SIZE （512K） 区块中执行 compress_file_range（），这些区块将调用该范围内的 btrfs_folio_clamp_clear_dirty（）。
    对于非子页面，这将始终安全地清除整个作品集。对于子页面，我们在这里也冒着部分清除的风险。特别是，想象一个 2M 作品集被分解成 512K 的工作块，这些工作块可能会在所有块 compress_file_range（） 工作线程足够远以完成清除作品集的所有脏位图并进入 folio_clear_dirty_for_io（） 之前开始对一个块进行压缩工作。提交范围边缘的大型作品集同样面临仅部分清除的风险。该系列中的另一个修补程序引入了这一特殊差距：提交 a4ef54dbb576（btrfs：使 extent_range_clear_dirty_for_io（） 处理扇区大小<页面大小情况）我们不能简单地将调用还原为 folio_clear ---truncated--- （CVE-2026-89772）

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

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

  - nfsd：通过 argp->mask 保护 nfs2 setacl NFSACL v2 SETACL 路径共享其 v3 同级使用的解码器约定：nfsaclsvc_decode_setaclargs（） 仅当在请求掩码中设置了 NFS_ACL 时才填充 argp->acl_access，而仅当设置了 NFS_DFACL 时才填充 argp->acl_default，而将另一个指针保留为空，因为参数缓冲区在解码前将参数缓冲区归零到 pc_argzero。然后，nfsacld_proc_setacl（） 会无条件地将两个指针都交给 set_posix_acl（）。set_posix_acl（idmap， dentry， type， NULL） 是 VFS 删除此 ACL 类型操作，因此省略的 arm 无法与删除该 ACL 的显式请求区分开来。仅携带 NFS_ACL 的 SETACL 会静默剥离目录的默认 ACL;mask=0 剥离两者。这与刚才在 nfsd3_proc_setacl（） 中修复的缺陷相同;应用相同的补救措施。保护每个掩码位上的每个 set_posix_acl（） 调用并将错误初始化为 0，使得未设置任何一位的请求保持磁盘上的 ACL 不变并返回成功。out_drop_lock 路径和 nfsaclsvc_release_setacl（） 中的无条件 posix_acl_release（） 已经容忍跳过的 arm。（CVE-2026-89672）

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

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

  - net：dsa：realtek：使用 gpiod_set_value_cansleep 进行重置仅从探测路径调用 GPIO rtl83xx_reset_assert（） 和 rtl83xx_reset_deassert（），这可能会休眠，并且对时序不重要。
    当重置 GPIO 由休眠控制器（例如 I2C I/O 扩展器）提供时，gpiod_set_value（） 警告： WARNING： drivers/gpio/gpiolib.c：4030 at gpiod_set_value+0x44/0x80， CPU#1： kworker/u16：4/61 硬件名称： B&O MAP CA33 Rev f （UNKNOWN） （DT） 工作队列： events_unbound deferred_probe_work_func pc：
    gpiod_set_value+0x44/0x80 LR ： rtl83xx_probe+0x1d8/0x3a0 调用跟踪：gpiod_set_value+0x44/0x80 （P） rtl83xx_probe+0x1d8/0x3a0 realtek_mdio_probe+0x24/0xa0 mdio_probe+0x38/0x78 really_probe+0xc4/0x3e0
    __driver_probe_device+0x15c/0x1b8 driver_probe_device+0xb4/0x120 __device_attach_driver+0xb8/0x1a0 bus_for_each_drv+0x88/0xf0 __device_attach+0xa0/0x1d8 device_initial_probe+0x54/0x68 bus_probe_device+0x38/0xa0 deferred_probe_work_func+0xb8/0x120 process_one_work+0x184/0x4e8 worker_thread+0x188/0x308 kthread+0x130/0x150 ret_from_fork+0x10/0x20 将两个辅助函数切换到 gpiod_set_value_cansleep（），以便在没有的情况下使用此类重置 GPIO触发警告。自从 v4.19 中添加驱动程序以来，重置 GPIO 一直使用非休眠 gpiod_set_value（） 驱动。此后，已跨多个文件重构此调用 - 从 realtek-smi.c / realtek-mdio.c 重构到通用的 rtl83xx.c 模块，然后重构到 rtl83xx_reset_assert（） 和 rtl83xx_reset_deassert（） 辅助函数（两者均在 v6.9 中）。因此，此修补程序仅按原样适用于携带这些帮助程序的内核 （v6.9+）;较旧的稳定内核需要在相应开放代码调用站点进行相同的 gpiod_set_value_cansleep（） 转换。
    (CVE-2026-80999)

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

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

  - nfsd：异步 COPY 循环 _nfsd_copy_file_range（） 之前的样本回写错误光标在复制循环之后将 dst->f_wb_err 采样到，然后在 vfs_fsync_range（） 返回时通过 filemap_check_wb_err（） 用它来检测回写错误。由于 nfsd_file 缓存会跨针对相同 inode 的请求重复使用单个结构文件，因此 dst 上的并行 COMMIT 或稳定 WRITE 会在其自己的 vfs_fsync_range（） 期间，通过 file_check_and_advance_wb_err（） 将 dst->f_wb_err 推进到当前映射>wb_err。如果该进步介于 mapping->wb_err 中出现的回写错误和 COPY 工作线程采样之间，因为工作线程捕获已经推进的光标，errseq_check（） 会看到 cur == since 并返回零，并且即使回写失败也会设置NFSD4_COPY_F_COMMITTED。CB_OFFLOAD然后编码 wr_stable_how = FILE_SYNC4，客户端将复制的数据视为持久数据，失败将变为静默数据丢失。从函数开始时开始采样一次。然后，光标会在此 COPY 发出任何写入之前反映有效的状态，并且 filemap_check_wb_err（） 会检测复制期间发生的任何错误，而不管哪个线程首先观察到它。这与 nfsd_vfs_write（） 和 nfsd4_clone_file_range（） 使用的模式相匹配。
    (CVE-2026-89704)

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

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

  - ipmi：修复 _ipmi_destroy_user（） 提交 9e91f8a6c868 中cmd_rcvr的释放后使用（ipmi：msghandler：删除 ipmi_interfaces 列表的 srcu） 删除了命令接收器与 intf->cmd_rcvrs 断开链接和释放命令接收器之间的synchronize_rcu（），仅更新说明为什么需要屏障的注释。
    cmd_rcvrs列表仍在普通 RCU 下遍历：find_cmd_rcvr（） 在 rcu_read_lock（） 内部遍历它，而 handle_ipmb_get_msg_cmd（） 则在同一读取端部分内从该查找借用 rcvr->user。
    如果没有宽限期，则 _ipmi_destroy_user（） 可在阅读器仍持有指向该cmd_rcvr的指针时对其进行 kfree（），从而导致释放后使用。重做仅使接口列表不需要 srcu;cmd_rcvrs列表仍然依赖于普通 RCU。释放接收器之前还原 synchronize_rcu（）。
    (CVE-2026-89486)

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

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

  - orangefs：修复 readdir 复制失败时的trailer_buf双重释放 在 readdir 下行调用中，当 copy_from_iter_full（） 失败时，orangefs_devreq_write_iter（） 通过 vfree（） 释放 op->downcall.trailer_buf，但是未在转到 Efault 之前清除指针。然后，do_readdir（） 中的等待程序会以负状态被唤醒，并在其 r < 0 路径上再次释放相同指针，从而造成确定性的双重释放。保留 /dev/pvfs2-req 的客户端通过发送声明的 trailer_size超过其提供的字节的 readdir 下行调用来触发它。释放后清除指针，以便 readdir 端的 vfree（） 变为非操作。（CVE-2026-89498）

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

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

  - ntfs：验证非驻留属性偏移 ntfs_attr_update_meta（） 在非稀疏属性和稀疏属性之间转换时会改变属性名称。转换为稀疏也会在名称和映射对之前添加compressed_size字段，从而要求属性记录中增加八个字节。
    但是，验证器不会检查name_offset是否在这些操作的安全边界内，或者是否有额外的可用空间。恶意 MFT 记录可将name_offset设置为：1. 名称位于非稀疏属性的最末尾。转换为稀疏会使名称向前移动 8 个字节，写入超出属性边界。2. 名称与映射对重叠，导致转换过程中损坏。添加验证以确保：- 对于命名的属性，name_offset在有效范围内 - 名称不会超出属性或与映射对重叠 - 对于非稀疏、非压缩的属性，compressed_size字段mapping_pairs_offset之后有八个字节可用空间检查还包括未命名的属性，其 name_offset = 0 有效且不需要检查名称范围。（CVE-2026-89611）

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

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

  - mm：memcg：限制更新被取代时停止回收 kernfs 仅对每个打开的文件进行序列化文件操作，因此单独的打开文件可同时更新相同的 memory.high 或 memory.max 文件。两个处理程序都会在同步回收之前存储新限制，但在回收循环中继续使用写入器的本地目标。如果另一个写入器提高或删除限制，则第一个写入器可以继续向过时目标回收。对于memory.max，一旦回收重试耗尽，这可使写入器无限循环。OOM 路径在当前限制下看到足够的边距，并在不终止的情况下返回 true，而写入器仍将使用情况与其过时目标进行比较并记录另一个 OOM 事件。
    在每次回收迭代开始时检查当前限制，如果不再符合写入器的目标，则停止。复制器：使用匿名内存填充 cgroup 并禁用交换。降低一个打开文件的memory.max，然后在新的限制可见后通过另一个打开的文件将其还原到最大。如果没有修补程序，则第一个写入器将保持阻断状态，并且会反复增加 OOM 事件计数器。使用该修补程序后，它可正常返回。并非报告的生产工作负载。我们通过对 cgroup 可观测性的自动随机测试发现了它，并将其简化为上面的复制品。（CVE-2026-89752）

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

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

  - mm/migrate：报告 migrate_pages_batch（） 中的 RCU 任务静止状态 migrate_pages_batch（） 在移动每个作品集之前先取消映射每个作品集，并且每次取消映射都会运行mmu_notifier无效回调。在 KVM 主机上，try_to_migrate（） 会以 kvm_mmu_notifier_invalidate_range_start（） -> tdp_mmu_zap_leafs（） 结束，这成本很高，因此取消映射大型批次会使 CPU 长时间处于忙碌状态。循环已经调用了 cond_resched（），但在 PREEMPTION 内核上这是无操作，非自愿优先权不是 Tasks-RCU 静止状态。因此，长批次永远不会报告静止状态，并且迁移任务（例如
    kcompactd） 变成 Tasks-RCU 保留项，使 Tasks-RCU 宽限期停止数分钟，这在 Meta fleet 中很常见：INFO： rcu_tasks 检测到任务停止：00000000055349ecc： ..nvcsw：1157401/1157401保留：1 idle_cpu：-1/56 task：kcompactd0 state：R 运行任务调用跟踪：tdp_mmu_zap_leafs tdp_mmu_next_root gfn_to_pfn_cache_invalidate_start kvm_mmu_notifier_invalidate_range_start
    __mmu_notifier_invalidate_range_start try_to_migrate_one try_to_migrate migrate_pages_batch migrate_pages compact_zone compact_node kcompactd kthread：使用 cond_resched_tasks_rcu_qs（），以便即使 cond_resched（） 不执行任何操作也报告静止状态。[1] （CVE-2026-89756） 中也讨论了这一点

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

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

  - openvswitch：仅 skb_tx_error（） 我们即将丢弃的数据包 queue_userspace_packet（） 借用数据包 skb -- 它仅将其复制到私有 netlink 消息 （user_skb） 中，并不拥有该消息;返回时，do_execute_actions（） 通过流的剩余操作不断转发它。尽管如此，其错误路径还是会调用 skb_tx_error（skb），后者通过 skb_zcopy_clear（） 进行 skb_shinfo（skb）->flags &= ~SKBFL_ALL_ZEROCOPY，从该实时 skb 剥离SKBFL_SHARED_FRAG（skb_tx_error（） 的 kerneldoc 说之后必须释放 skb）。对于携带页面缓存碎片的 skb MSG_ZEROCOPY，SKBFL_SHARED_FRAG使 esp_input（） 在就地 AEAD 之前skb_cow_data（）;一旦剥离，稍后的本地 ESP-in-UDP 传递将在非发送者拥有的页面上就地解密 -- 非特权页面缓存写入（Fragnesia 原语）。do_execute_actions（） 会忽略 output_userspace（） 的返回值，因此 USERSPACE 上行调用失败之后的任何操作均可继承剥离的 skb。将 skb_tx_error（） 移动到 flow-miss 丢弃路径 - ovs_dp_process_packet（） 的 switch（error） 的默认分支），在 kfree_skb（） 之前。自提交 36d5fe6a0007 以来，此调用一直存在（核心、nfqueue、openvswitch：skb_zerocopy 中的孤立 frag 并处理错误），但在 esp_input（） 开始依赖 SKBFL_SHARED_FRAG 来控制就地解密之前没有任何危害;只有到那时，在仍在转发的 skb 上剥离它才成为页面缓存写入原语。（CVE-2026-89487）

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

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

  - timers/itimer：复制到用户空间之前的零初始化旧 itimerval 在 native sparc64 中，struct
    __kernel_old_timeval 在tv_usec后包含一个四字节的空洞，因为 tv_sec 是 64 位的，而
    __kernel_suseconds_t 是 32 位的。put_itimerval（） 仅填充堆栈分配的命名字段
    __kernel_old_itimerval并将整个对象复制到用户空间，因此 getitimer（） 可暴露这两个填充孔。在分配字段之前对聚合进行零初始化，以便在隐式填充跨越用户/内核边界之前具有确定性。（CVE-2026-89765）

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

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

  - nfsd：解决 filecache 中的 shrinker/GC/fsnotify 与 per-net 关闭争用 shrinker、GC 工作线程和 fsnotify/lease 回调可从 rhashtable 中对nfsd_file反哈希，然后调用 nfsd_file_dispose_list_delayed（） 将其移动到 per-net 处置列表。如果 nfsd_file_cache_shutdown_net（） 并发运行，则其 rhashtable walk 会错过已未哈希的文件，并且其对 per-net 处置列表的耗尽可在文件排队之前运行。然后该文件位于 per-net 列表中，没有线程可耗尽它，从而同时泄漏该文件及其相关状态。GC worker 和 shrinker 在遍历 LRU 时已经持有 nfsd_gc_lock，但在原始代码中，它们在调用 nfsd_file_dispose_list_delayed（） 之前将其释放。fsnotify/租用路径 （nfsd_file_close_inode） 完全没有同步。通过以下方式修复此问题：1. 扩大 nfsd_file_gc（） 和 nfsd_file_lru_scan（） 中的nfsd_gc_lock以覆盖 nfsd_file_dispose_list_delayed（） 调用。2. 将 nfsd_file_close_inode（） 封装在 nfsd_gc_lock 中，以便 nfsd_file_dispose_list_delayed（） 的所有三个调用方都保持锁定。3. 在清除后在 nfsd_file_cache_shutdown_net（） 中添加一个 spin_lock/unlock（nfsd_gc_lock） 屏障，以便在耗尽 per-net 列表之前完全完成任何正在进行的处置。锁定内的所有操作均为非休眠（rhashtable 查找、原子位/引用计数操作、列表移动svc_wake_up），因此旋转锁是合适的。（CVE-2026-89667）

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

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

  - rust：devres：修复并发撤消程序之间的争用 两条路径尝试同时撤消 Devres 时存在潜在争用条件。驱动程序核心的 devres_release_all（） 通过释放回调调用 Revocable：：revoke（），而 Devres：:d rop（） 会在另一个 CPU 上调用 revoke_nosync（）。未声明 is_available swap 的撤消器会立即返回，但声明交换的撤消器可能仍在对内部数据执行 drop_in_place（）。当其他撤消者的调用程序继续丢弃 drop_in_place（） 仍然引用的相邻资源时，这可造成释放后使用（例如，Devres<DmaMappedSgt> 与 SGTable 争用，从而释放后备sg_table和页面）。通过添加 Completion 修复此问题。释放回调在 revoke（） 完成后发出完成信号，Devres：:d rop（） 在失去is_available交换时等待它。这可确保封装的对象在 Devres：:d rop（） 返回前完全拆散。
    (CVE-2026-89764)

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

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

  - net：tun：绑定接收余量 tun_get_user（） 使用 tun->align 作为 skb 余量和选择要保持线性的数据包数据量时。OVS 可以将超大的余量请求从另一个端口传播到 TUN 或 TAP。当 align 大于单页 skb 标题中的可用空间时，SKB_MAX_HEAD（align） 会下溢，并且结果在存储在 good_linear 中时变为负值。该值稍后在分配给 size_t 线性变量时进行封装，并且 tun_alloc_skb（） 可以将 skb->data 放在分配的 head 之外。将 TUN 存储的余量绑定到一页 skb-head 预算和最大的非 sentinel 16 位 skb 标头偏移量。为原始 TUN 保留一个线性字节，为 TAP 保留一个完整的以太网标头，包括 NET_IP_ALIGN。
    此外，在访问 raw-TUN 协议字节和 TAP 以太网标头之前也请提取它们，以便对于其他分配路径提供的非线性 skb 保持这些检查安全。（CVE-2026-81000）

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

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

  - pidfd：保持命名空间 ioctl 周围的exec_update_lock pidfd_ioctl（） 中的 PIDFD_GET_*_NAMESPACE ioctls 在分发命名空间文件描述符之前执行文件系统凭据 ptrace 访问检查。随附的注释指出代码反映了 nsfs 行为，但与相应的 procfs 路径不同的是，它这样做并不保留目标任务的exec_update_lock。proc_ns_get_link（） 和 proc_ns_readlink（） 都采用 exec_update_lock 进行 ptrace 检查和命名空间查找的读取，以便读取任务命名空间时用于访问决策的凭据与任务的凭据匹配。没有该选项时，调用程序可通过针对目标旧凭据的检查，然后在目标执行 setuid 二进制文件并提交新凭据之后读取命名空间 -- 访问本应被拒绝的命名空间信息。保留 exec_update_lock 以读取 ptrace 检查和命名空间查找，以便 pidfd 真正反映 nsfs 行为，正如注释中已经声明的那样。
    open_namespace（） 本身在锁定之外运行：一旦获得命名空间引用，它就带有自己的 refcount，并以调用者自己的凭据打开，因此目标上的并发 execve（） 不再影响结果。（CVE-2026-89766）

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

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

  - svcrdma：当传输分配失败时拒绝连接 handle_connect_req（） 无法分配新的传输时 svc_rdma_create_xprt（） 返回而不执行任何操作。CM 核心对CONNECT_REQUEST事件返回 0，因此它不会破坏新rdma_cm_id。内存压力下的每个分配失败都会泄露一个rdma_cm_id，驱动连接尝试的远程对等机可放大此漏洞。通过从 CM 事件处理程序返回非零状态来拒绝连接，这会指示 CM 核心破坏孤立的cm_id。CVE-2026-89531

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

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

  - ecryptfs：拒绝来自标签 3 数据包正文的 parse_tag_3_packet parse_tag_3_packet（） 设置encrypted_key_size中的超大encrypted_key_size，不针对ECRYPTFS_MAX_KEY_BYTES （64） 进行边界限制。
    当encrypted_key_size > 64 时，decrypt_passphrase_encrypted_session_key（） 设置 decrypted_key_size = encrypted_key_size 并执行两次越界写入：1. crypto_skcipher_decrypt（） 通过 scatterlist 将encrypted_key_size字节写入 decrypted_key[64]，从而溢出到父 ecryptfs_auth_tok struct。2. memcpy（crypt_stat->key， decrypted_key， decrypted_key_size） 写入 crypt_stat->key[64]，损坏 ecryptfs_crypt_stat中的 root_iv、keysig_list 和互斥体。只有 AES-192（密码代码 0x08）启用此功能，因为它独立于 encrypted_key_size 设置 crypt_stat->key_size = 24，从而允许 crypto_skcipher_setkey（） 在超过 ECRYPTFS_MAX_KEY_BYTES 时encrypted_key_size成功。PKI 解密路径 （parse_tag_65_packet） 已验证 decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES;密码路径忽略了该检查。针对 ECRYPTFS_MAX_KEY_BYTES （64） 而非 ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES （512） 绑定encrypted_key_size。64 字节限制也保护了 512 字节 encrypted_key[] 缓冲区，因此先前的 512 字节检查会因多余而删除。
    [tyhicks： 调整代码注释以引用表示缓冲区大小的宏，而不是提及缓冲区大小值，因为这些值将来可能会更改]（CVE-2026-89607）

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

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

  - kho：修复 kho_preserved_memory_reserve（） 中的大小计算 kho_preserved_memory_reserve（） 通过执行 1 次<< （order + PAGE_SHIFT） 来计算存储的大小。由于“1”是 32 位整数，因此只能移动 31。也就是说，它仅适用于高达 2 GiB 的存储。较大的保留将触发未定义的行为。虽然目前无法通过对开本获得大于 2 GiB 的保存，但可以通过 kho_preserve_pages（） 获得。例如，memblock reserve_mem使用 kho_preserve_pages（）。大于 2 GiB 的保留有效，如果正确对齐则将触发此缺陷。通过使用 1UL 进行换挡来修复它。（CVE-2026-89568）

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

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

  - nfsd：不释放仍在使用的会话槽 nfsd4_sequence（） 可释放目前正在处理的槽。当会话 shrinker se_target_maxslots低于 se_fchannel.maxreqs 时，shrink 路径会在调用 free_session_slots（） 之前检查三个条件： 1.se_target_maxslots < maxreqs（已公布收缩） 2..slot->sl_generation == se_slot_gen （插槽是最新的） 3.
    seq->maxslots <= se_target_maxslots（客户端确认）但是，从未针对se_target_maxslots检查 seq->slotid。使用 [se_target_maxslots， maxreqs） 范围内插槽的客户端可满足所有三个条件：其插槽具有当前生成（由之前的 SEQUENCE 设置），并且发送 sa_highest_slotid <= se_target_maxslots 以确认减少。然后，free_session_slots（） 释放索引 >= se_target_maxslots 处的每个插槽，包括调用者自己的插槽。该函数继续写入 sl_seqid、sl_flags、sl_generation，并将悬摆指针存储在 cstate->slot 中。随后，nfsd4_store_cache_entry（） 将复合回复中最多 maxresp_cached 字节复制到释放的 sl_data[] 数组中，从而损坏现在占据该地址的任何 slab 对象。此外，另一个高编号插槽中的并行线程处理 SEQUENCE 可从其下方释放其插槽。释放锁定之前，NFSD4_SLOT_INUSE 已设定在 nn->client_lock 之下，因此任何并发线程超过 SEQUENCE 都会被标记其插槽。但是，free_session_slots（） 不会在释放前检查NFSD4_SLOT_INUSE。通过以下方式修复这两个问题：1. 检查当前请求的 slotid 是否在收缩边界以下。2. 扫描待释放范围内的插槽以进行NFSD4_SLOT_INUSE，如果有活动，则延迟收缩。（CVE-2026-89689）

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

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

  - nfsd：修复异步副本取消和关闭中的 UAF 当拆卸调用程序（OFFLOAD_CANCEL、nfsd4_shutdown_copy nfsd4_cancel_copy_by_sb）对复制进行争用时，可释放异步副本或在释放后使用 kthread： - find_async_copy（） 升级了 copy->refcount，但保留了 clp->async_copies 上的副本，因此 reaper 的 cleanup_async_copy（） 可与取消/关闭调用程序并发运行 release_copy_files（）。put 和 NULL nf_src/nf_dst无通用锁定，双重放置 nfsd_file并提早释放。- nfsd4_do_async_copy（） 在最终使用副本之前设置 NFSD4_COPY_F_STOPPED（copy->nf_dst 上的 nfsd_update_cmtime_attr（），nfsd4_send_cb_offload（））。nfsd4_stop_copy（） 将设置的 STOPPED 位视为 kthread 完成，跳过 kthread_stop（），因此拆卸调用程序在 kthread 仍在取消引用它时运行 release_copy_files（） -- 这会nf_dst置 NULL （NULL/UAF）。- 从未固定 copy->copy_task。一次性 kthread 在返回时会自我收获，因此 kthread_stop（） 的 get_task_struct（） 可接触释放的task_struct。- co_cb嵌入在副本中，但 nfsd4_send_cb_offload（） 仅在客户端上保留引用，因此并发拆卸可在 CB_OFFLOAD 回调执行时释放副本。将拆卸生命周期整体修复：- find_async_copy（） 取消链接 async_lock 下的副本（清除 cp_clp、list_del_init）;cancel、shutdown 和 sb-cancel 路径通过 nfsd4_stop_copy（） 之后的 nfs4_put_copy（） 丢弃 list-membership 引用。从 cleanup_async_copy（） 中放弃现在冗余的 list_del 修复。
    - 由于取消链接会对死神隐藏副本，因此其 cleanup_async_copy（） 无法再删除副本的s2s_cp_stateids条目;cancel/shutdown/sb-cancel 路径现在会自行调用 nfs4_free_copy_state（），cp_clp仍然有效），因此该条目不会悬摆在释放的内存上，以便 laundromat 和 manage_cpntf_state（） 取消引用。- 为 kthread 提供自己的引用，在 wake_up_process（） 之前的 nfsd4_copy（） 中获取并在 nfsd4_do_async_copy（） 结束时终止;先调用 wake_up_process（），然后再调用 list_add（）。- 通过 nfsd4_copy（） 中的 get_task_struct（） 固定 task_struct，在 nfs4_put_copy（） 中释放，这样 kthread_stop（） 在退出 kthread 时都是安全的。仅在 nfsd4_stop_copy（） 中设置 NFSD4_COPY_F_STOPPED，现在始终在 release_copy_files（） 之前kthread_stop（）s;完成情况仍通过 NFSD4_COPY_F_COMPLETED 报告，因此 nfsd4_has_active_async_copies（） 不受影响。每个拆卸调用程序首先从 clp->async_copies 中删除副本，因此 kthread_stop（） 只运行一次。- 在 nfsd4_send_cb_offload（） 中获取复制引用，在 nfsd4_cb_offload_release（） 中丢弃。kthread 仍然保留自己的引用，因此 refcount_inc（） 不能争用最终释放。- 通过 smp_load_acquire（） 读取cp_clp以与无序的 set_bit）/clear_bit（） 写入器配对 （Documentation/atomic_bitops.rst）。（CVE-2026-89675）

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

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

  - efivarfs：速率限制 statfs（） 处理程序 Ravi 报告，efivarfs 挂载点上的非特权用户可能会调用 statfs（），从而可能导致对 QueryVariableInfo（） 运行时服务的大量调用。
    在变量存储由 SMM 提供支持的 x86 系统上，这些调用成本过高，因为每个 SMM 条目都需要所有 CPU 的集合。因此，将对 QueryVariableInfo（） 的调用速率限制为每秒两次，并为省略的调用返回最近获得的值。（CVE-2026-89604）

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

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

  - HID：mcp2221：I2C/SMBus 传输完成后清除 rxbuf mcp_i2c_smbus_read（） 在传输期间将调用程序提供的缓冲区指针存储在 mcp->rxbuf 中，但从不在传输完成或超时时清除。一旦调用程序释放或重新使用缓冲区，mcp->rxbuf 就会变成悬摆指针。
    然后，延迟或虚假的 MCP2221_I2C_GET_DATA 报告可驱动 mcp2221_raw_event（） memcpy 设备数据，使其进入释放的内存，导致写入释放后使用。通过一个清除 mcp->rxbuf 和 mcp->rxbuf_size 的退出点路由所有返回路径，以便 raw_event 处理程序中现有的 ！mcp->rxbuf 防护可以拒绝传输结束后到达的任何报告。（CVE-2026-89622）

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

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

  - dm-era：修复 take-snap 失败时的隐藏超级块泄漏 metadata_take_snap（） 升级实时超级块引用计数，然后 dm_tm_shadow_block（） 为元数据快照分配一个新块。如果后续的 writeset_tree_root 或 era_array_root dm_sm_inc_block（） 失败，该函数仅会解锁克隆并返回。新分配的阴影块永远不会返回到元数据空间映射，因此每个失败的 take-snap 都会永久泄漏一个元数据块。在这些错误路径中使用 dm_sm_dec_block（） 释放克隆，与 metadata_drop_snap（） 的最后一步相匹配。（CVE-2026-89576）

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

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

  - dm-io：单独报告不可重试的错误 错误代码 BLK_STS_NOTSUPP 和 BLK_STS_INVAL 不应造成 dm-raid1 上的 leg 失败。此修补程序会将界面更改为 dm-io，从而报告两个错误位图 - error_bits 和 unsup_bits。unsup_bit位图跟踪BLK_STS_NOTSUPP或BLK_STS_INVAL错误，error_bits位图跟踪所有其他错误。dm-raid1 已更改，以便当它在 unsup_bits 位图中收到错误时不会使 leg 发生故障。此修补程序（含 62dc37a819a5）可修复用户在 dm-raid1 上使用未对齐的 bio 向量时的不当行为。（CVE-2026-89577）

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

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

  - dm-stats：修复当分配每个 cpu 的数据失败时的崩溃问题 如果 dm_kvzalloc（percpu_alloc_size， cpu_to_node（cpu）） 失败，代码将跳转到 out 标签并调用 dm_stat_free。dm_stat_free for_each_possible_cpu（cpu） { dm_kvfree（s->stat_percpu[cpu][0].histogram， s->histogram_alloc_size）;，如果 s->stat_percpu[cpu] 为空，它会因空指针取消引用而崩溃。此提交通过在使用之前测试 s->stat_percpu[cpu] 是否为空，来修复该缺陷。（CVE-2026-80963）

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

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

  - fpga：altera-cvp：避免尾部字节写入中的越界读取 altera_cvp_send_block（） 中的尾部字节路径会取消引用 u32 指针，即使输入缓冲区中仅剩 1-3 个字节也是如此。如果缓冲区以页面或分散列表边界结束，这可能会读取超过有效图像数据并发生错误。在写入最后一个字之前，将其余字节复制到零初始化的 u32 中，以便从输入缓冲区只读取有效的字节。（CVE-2026-89730）

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

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

  - vsock/virtio：刷新按依存关系顺序运行 virtio_vsock_remove（） 会停止 virtqueues，然后刷新每个工作项，然后再释放封闭的virtio_vsock。当前顺序不考虑这些项目之间的依赖关系：tx_work 可能会send_pkt_work排队，send_pkt_work可能会排队rx_work。特别是，send_pkt_work可以设置restart_rx和释放tx_lock。然后，该删除路径可在send_pkt_work排队之前停止队列并刷新rx_work。尽管后面的 send_pkt_work 刷新会等待生产者完成，但不会等待新排队的rx_work，因此 kfree（vsock） 可与之争用。KASAN 报告：缺陷：KASAN：任务 kworker/1:1/47 在地址 ffff888114c2b008 的 virtio_transport_rx_work+0x487/0x4b0 中的 slab-use-after-free 读取：virtio_vsock virtio_transport_rx_work 调用跟踪：
    virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 按任务 1 分配：virtio_vsock_probe+0xef/0x6b0 由任务 84 释放：kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 按生产者到消费者的顺序刷新作品。virtio_vsock_vqs_del（） 已禁用队列回调并清除运行标记，因此当耗尽 tx_work 和 send_pkt_work 之后，将不再有源可以在其刷新之后rx_work排队。（CVE-2026-80932）

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

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

  - i3c：修复 i3c_device_get_supported_xfer_mode（） 中 dev->desc 的解锁取消引用 i3c_device_get_supported_xfer_mode（） 使用 dev->desc 获取主控制器。但是，除非持有 bus->lock，否则不得取消引用 dev->desc，并且此函数不会锁定该锁。该功能只需要访问与设备总线关联的主控制器。请改用 dev->bus，它在设备的整个生命周期内始终有效，并且不需要取消引用 dev->desc。
    (CVE-2026-80954)

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

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

  - NFSD：删除nfsd_mode_check中有缺陷的WARN_ON_ONCE 提交 e75b23f9e323（nfsd：目录fh_verify中的检查d_can_lookup）的标头详细说明了可证明将WARN_ON_ONCE添加至nfsd_mode_check（）的合理性的假设，该假设无效（在 NFS 重新导出的情况下）。NFSD 导出 NFS 文件系统时，nfsd_mode_check（） 很可能会遇到没有 i_op->lookup 的@dentry（请参阅 nfs_fhget（） 的 NFS_ATTR_FATTR_MOUNTPOINT 和 NFS_ATTR_FATTR_V4_REFERRAL 处理，以及 d_flags_for_inode（））。因此删除 nfsd_mode_check（） 的 WARN_ON_ONCE（）。该分支的nfserr_notdir回报必须保留。它保护后续的 lookup_one_unlocked（） -> __lookup_slow（） 路径，该路径调用不进行 NULL 检查的 inode->i_op->lookup（），因此返回nfserr_notdir是阻止此类@dentry的客户端 LOOKUP 取消引用空方法指针的原因。（CVE-2026-89711）

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

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

  - usb：typec：thunderbolt：在删除 tbt_altmode_remove（） 时释放 tbt 之前禁用工作，在不耗尽 tbt-> 工作的情况下删除插头和电缆引用。work 函数会取消引用这些引用，并且还可以在其错误路径中重新排队。VDM 回调可以将同一工作项排队。禁用并耗尽 tbt->work，然后再终止引用。这将等待现有调用并防止后续 schedule_work（） 调用在拆卸期间将其排队。此问题由内部静态分析工具发现，并通过手动代码审查确认。（CVE-2026-89737）

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

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

  - s390/dasd：不完成失败的 ESE 读取，因为成功的 dasd_int_handler（） 会调用 ese_read（） 并无条件地将请求标记为DASD_CQR_SUCCESS，从而完成对未分配 ESE 跟踪的 NRF 读取。
    dasd_eckd_ese_read（） 可在将目标缓冲区清零之前返回错误：失败的感知数据解析或请求范围之外的当前跟踪都会提前返回，从而不影响目标页面。请求仍会顺利完成，因此块层会收到过时 / 未初始化的内存，而非零。检查 ese_read（） 返回值并通过正常错误路径使请求失败，而非强制DASD_CQR_SUCCESS。（CVE-2026-89458）

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

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

  - nfsd：保持 localio cmpxchg 上的 RCU 重试nfsd_file通过 call_rcu （filecache.c：296） 释放对象，并且在不SLAB_TYPESAFE_BY_RCU的情况下创建nfsd_file_slab （filecache.c：789 的 KMEM_CACHE（nfsd_file， 0），因此，一旦 RCU 宽限期过后，支持已释放nfsd_file的 slab 页面将可自由回收。
    nfsd_open_local_fh（） 中的 again： retry 块使用 cmpxchg 加载指针，然后在不按住 rcu_read_lock 的情况下调用 nfsd_file_get（new）（refcount_inc_not_zero）。唯一调用程序 nfs_open_local_fh（） 在调用此帮助程序之前就丢弃了 rcu_read_lock，因此没有外部读取器端关键部分涵盖负载。CPU 0 （nfsd_open_local_fh） CPU 1 （nfsd_file_put_local） ----- ----- new = cmpxchg（pnf， NULL， ...） nf = xchg（pnf， NULL） nfsd_file_put（nf） last ref -> call_rcu（） /* 宽限期已过;slab 页面回收 */ nfsd_file_get（新） refcount_inc_not_zero（&new->nf_ref） /* 在回收内存上操作 */ 回收对象的nf_ref偏移处的非零字使 refcount 升级看似成功，然后调用程序随后从释放的内存中取消引用 new->nf_net 和 new->nf_file。通过在 cmpxchg 之前取 rcu_read_lock（），然后在 if（新）块的所有三个出口上将其释放来修复：goto-again 重试、丢失的争用清理路径和安装成功路径。
    nfsd_file_put（） 和 nfsd_net_put（） 位于 RCU 部分外部，因此可以自由阻断。
    (CVE-2026-89670)

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

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

  - Perl 的 DBI 之前版本 1.653 通过 DBD：:D BM 中未经验证的 dbm_type 和dbm_mldbm属性加载任意模块。DBD：:D BM 将 dbm_type 和 dbm_mldbm 连接属性传递为需要，而未检查该值是否命名模块。Require 将路径形状的字符串视为文本文件名并且不咨询@INC，因此该属性选择 Perl 加载和运行的文件。The MLDBM::Serializer::
    DBD：:D BM 预加到 dbm_mldbm 的前缀不是边界：只有 ：： 分隔符会重写为 /，因此包含 / 的值会遍历序列化程序目录之外。该值还分配给 $MLDBM：：Serializer，MLDBM 在绑定表时以相同的方式要求该方法。让不受信任的一方影响任一属性（例如通过 DSN 片段或选择存储后端的参数）的调用程序将运行该值命名的任何模块的文件范围代码。例如，my $dsn = dbi：DBM：f_dir=/var/db;dbm_type=../../Untrusted.pm my $dbh = DBI->连接（ $dsn ）;请注意，DBD：：Gofer 将连接属性转发到服务器端，而 DBI：:P roxyServer 仅检查 DSN 是否以驱动程序前缀开头。（CVE-2026-78030）

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

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

  - ring-buffer：修复 subbuf 与环缓冲区读取器的争用trace_buffer subbuf_size在 ring_buffer_read_page（） 和 ring_buffer_read_start（） 中处于无锁读取状态，同时可以通过 ring_buffer_subbuf_order_set（） 来调整大小。在 ring_buffer_read_start（） 和 ring_buffer_read_page（） 中使用 bpage：：order 代替 trace_buffer：：subbuf_size。在 ring_buffer_read_start（） 中，即使resize_disabled，仍可能因缓冲区修改而发生争用。保持trace_buffer互斥体以与任何待定环缓冲区顺序修改同步。trace_buffer：：subbuf_size 现在实际上无用，请将其删除。此外，还创建访问器 rb_subbuf_capacity（） 和 rb_page_capacity（），其返回可用于存储事件的实际大小，而 rb_subbuf_size（） 返回实际的 subbuf 页面大小。（CVE-2026-89771）

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

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

  - mm/vmscan：报告 shrink_lruvec（） 中的 RCU 任务静止状态 我发现回收期间 Meta 机群中有一些rcu_tasks停止。INFO： rcu_tasks 检测到任务的停止：00000000088620d09： ..nvcsw：6735/6735 holdout：1 idle_cpu：-1/8 task：GlobalCPUThread 状态：R 运行任务 pid：2552016 tgid：2524552 调用跟踪：
    shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages
    __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault 没有任何内容承诺在有限时间内直接回收返回，并且 shrink_lruvec（） 中的扫描循环仅调用 cond_resched（），这对 PREEMPTION 内核来说是无操作的。非自愿优先权不是 Tasks-RCU 静止状态，因此回收任务永远不会报告，而是变为保留。将其升级到 cond_resched_tasks_rcu_qs（），即使 cond_resched（） 不执行任何操作，该版本也会报告静止状态。PS：这已在 [1] （CVE-2026-89753） 中讨论过

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

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

  - fbdev：uvesafb：INIT 失败时取消注册连接器回调 uvesafb_init（） 会在注册平台驱动程序之前注册 v86d 连接器回调。如果 platform_driver_register（） 失败，该函数会直接返回错误，并使连接器回调保持注册状态。较新的平台设备故障路径已取消注册回调。当平台驱动程序注册失败时，在最终返回之前添加相同的清理。我们在查看内核代码时进行持续的静态分析研究中发现了此问题。（CVE-2026-89597）

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

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

  - svcrdma：修复空区块的pcl_for_each_segment 当解析的区块列表包含ch_segcount为零的区块时，pcl_for_each_segment 计算其包含上限为 &chunk->ch_segments[ch_segcount - 1]。ch_segcount是 u32，因此减法换行为 0xFFFFFFFF，绑定远远超过ch_segments flex 数组。然后，循环主体以 sizeof（struct svc_rdma_segment） 步幅遍历不相关的内存，直到发生错误。可从线路访问零段数区块：
    xdr_check_write_chunk（） 仅拒绝大于 rc_maxpages 的段数值，并且 pcl_alloc_write（） 在其段填充循环运行之前将新分配的区块链接到 rc_write_pcl/rc_reply_pcl，因此公告零段的写入或回复区块会在列表中留下 ch_segcount == 0。当传输协商 Send-With-Invalidate 时，svc_rdma_get_inv_rkey（） 会在每次迭代时通过pcl_for_each_segment和取消引用段>rs_handle迭代所有四个 PCL，将下溢转变为越界读取和一般保护错误。xdr_check_write_list / xdr_check_reply_chunk pcl_alloc_write（） chunk = pcl_alloc_chunk（...） /* ch_segcount = 0 */ list_add_tail（&chunk->ch_list， &pcl->cl_chunks） /* 填充循环对线路段数 0 迭代零次 */ svc_rdma_get_inv_rkey（） pcl_for_each_chunk（rc_write_pcl） pcl_for_each_segment（segment， chunk） pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */ segment->rs_handle /* OOB 读取 -> GPF */ 通过切换宏进行修复设置为直接使用 ch_segcount 的半开放上限。
    对于 ch_segcount == 0，循环开始等于循环结束，并且跳过正文;对于 ch_segcount > 0，迭代范围保持不变。net/sunrpc/xprtrdma/svc_rdma_recvfrom.c 和 net/sunrpc/xprtrdma/svc_rdma_rw.c 中的所有六个现有调用站点在新边界下保持正确，因此不需要更改调用程序。
    (CVE-2026-89532)

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

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

  - power：supply：ucs1002：修复删除时的释放后使用 ucs1002 没有 remove 回调，因此 unbind 完全通过 devm 运行。警报 IRQ 处理程序会将health_poll延迟的工作排队，并在芯片报告健康状况不佳时重新安排工作。devm 释放警报 IRQ，仅同步处理程序;它不会取消延迟的工作，而延迟的工作可以在 devm 释放驱动程序数据并取消引用之后运行。请求警报 IRQ 之前，请先向 devm_delayed_work_autocancel（） 注册health_poll。然后，devm 在取消工作之前释放 IRQ，这样处理程序就无法再将其排队，并且会在释放驱动程序数据之前取消工作。此问题由内部静态分析工具发现。（CVE-2026-89463）

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

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

  - smb：客户端：修复 coalesce_t2（） 中未经验证的 DataOffset 的越界读取/写入 coalesce_t2（） 直接从服务器提供的 DataOffset 字段计算数据指针，且未针对缓冲区边界进行验证：
    data_area_of_tgt = （char *）&pSMBt->hdr。协议 + get_unaligned_le16（&pSMBt->t2_rsp。DataOffset）;
    data_area_of_src = （char *）&pSMBs->hdr。协议 + get_unaligned_le16（&pSMBs->t2_rsp。DataOffset）;
    data_area_of_tgt += total_in_tgt;...memcpy（data_area_of_tgt、data_area_of_src、total_in_src）;小的 DataOffset 可以将指针推到实际字节区域下方，从而覆盖标头字段;大型堆栈可将其推过缓冲区末端，从而导致越界堆读取（源）或写入（目标）。BCC 溢出防护不会阻止这种情况：BCC 反映存在的数据量，而 DataOffset 控制数据在缓冲区中的开始位置。自 2005 年首次编写该函数以来，一直存在的验证目标区域注释是一个从未实现过的占位符。在 memcpy 之前和修改任何目标标头字段之前，对这两个数据指针添加下界和上界检查。(CVE-2026-89633)

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

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

  - io_uring/waitid：当 task_work_add（） 无法再将工作排队至原始任务时，遵守task_work取消 io_waitid_cb（） 可能通过回退task_work路径运行。回退从 kworker 运行，io_uring通过 tw.cancel 将此类任务工作标记为已取消。io_waitid_cb（） 当前忽略 tw.cancel 并调用 __do_wait（）。waitid 依赖于任务上下文：__do_wait（） 执行相对于当前的子查找，重试路径也使用 current->signal->wait_chldexit。如果回调从回退 kworker 运行，则当前不是提交请求的任务。进入 __do_wait（） 之前遵从 tw.cancel。使用 -ECANCELED 完成请求并跳过 siginfo 副本，因为取消的任务工作可能在没有提交任务的用户空间执行上下文的情况下运行。保留现有 siginfo 处理以进行正常 waitid 完成和显式取消。（CVE-2026-81010）

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

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

  - net/iucv：按入口设备过滤 afiucv_hs_rcv（） 中的帧 afiucv_hs_rcv（） 通过单独匹配传输标头中的四个 8 字节名称字段从iucv_sk_list中选择套接字。未对帧到达的net_device进行检查。这可造成到达任何 netdev 的帧被传递到AF_IUCV套接字。接下来有三个问题。首先，通过 HiperSockets 到达的帧可传送到绑定到经典 z/VM IUCV 传输（具有 iucv->hs_dev == NULL）的套接字。只要请求的 userid 与iucv_userid匹配，iucv_sock_bind（） 就会采用经典路径，即使在同时具有携带相同标识符的 HiperSockets 设备的客户机上也是如此。afiucv_hs_callback_syn（） 为此类匹配创建的子套接字继承了 hs_dev = NULL 和 transport = AF_IUCV_TRANS_HIPER，因此它的第一个 send（） 返回
    -埃诺德夫。交付给 accept（） 的套接字无法使用。第二种情况，到达一个 netdev 的帧可以传送到绑定到其他 IQD 设备的套接字。这可导致 - 接受队列耗尽 （DoS） - 子套接字中受攻击者控制的对等机身份 - 数据注入现有套接字 - IQD 结构上的结构噪音，发送虚假的回复 - 终止已建立的连接 第三，所有AF_IUCV套接字都位于init_net中，因为 iucv_sock_alloc（） 会调用 sk_alloc（&init_net， ...）。但是，即使是到达命名空间中 netdev 设备的帧，也可以传递到 IUCV 套接字。因此，非特权用户和网络命名空间中仅保留该命名空间内有效的 CAP_NET_RAW 功能的进程可在其自己的 lo 设备上发送原始 ETH_P_AF_IUCV 帧，并使其与init_net套接字进行匹配。通过跳过其hs_dev与入口设备不匹配的任何套接字，将这三个问题全部修复。经典 z/VM IUCV 套接字具有 hs_dev == NULL;ingress dev 永远不会是 NULL，因此会自动跳过经典套接字。未绑定的 HIPER 套接字也具有 hs_dev == NULL 并被跳过。绑定的 HIPER 套接字只能从与其绑定的确切 IQD 设备进行访问。由于 hs_dev 始终是 init_net 中的设备（iucv_sock_bind（） 扫描 for_each_netdev_rcu（&init_net， ...） 独占），因此入口设备属于另一命名空间的帧永远不会与任何套接字相匹配。请注意，通过 HiperSockets 的AF_IUCV不提供每个连接的认证：无序列号、无 TLS、无临时信息。识别连接的四个名称字段在共享的 HiperSockets 段 （VCHID） 上以明文形式交换。同一 HiperSockets 段上的任何主机都可针对现有连接欺骗任何帧类型。这是此修补程序未更改的协议级属性。此补丁将攻击面缩小为存在于相同 HiperSockets 段上的对等方。（CVE-2026-81003）

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

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

  - ecryptfs：清理后台程序队列时保持 msg ctx 列表锁定 ecryptfs_exorcise_daemon（） 在不保留ecryptfs_msg_ctx_lists_mux的情况下从垂死的后台程序中丢弃排入队列的消息，但 ecryptfs_msg_ctx_alloc_to_free（） 需要该锁定。将已排队的上下文移回空闲列表时，采用列表锁定以避免与其他全局 msg ctx 列表用户争用。（CVE-2026-89609）

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

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

  - dm-pcache：根据从 crc32c 专用超级块读取的缓存设备大小seg_num验证媒体上的seg_num，因此无论谁在表加载 （CAP_SYS_ADMIN） 上提供缓存设备，都可以对其进行控制。它会调整 cache->segments[] 大小，并且是与每个后续媒体区段 ID 绑定的值，但从未针对设备进行检查。由于 cache_dev->mapping 是 pmem 的直接映射，因此超过设备的段 id 的 CACHE_DEV_SEGMENT（） 解析为超出映射范围的普通内核内存;达到此类 id 的新缓存 init 在该内存上有 cache_seg_init（） -> cache_dev_zero_range（） memset（） 12 KiB -- 在表加载时对内核堆的越界写入。零seg_num使段分配ZERO_SIZE_PTR。拒绝使用前为零、大于设备可容纳的seg_num或大于 PCACHE_CACHE_SEGS_MAX 的。（CVE-2026-80960）

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

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

  - league/commonmark 之前 2.6.0 的版本在 Markdown 解析中包含多项式时间复杂度漏洞，允许攻击者造成拒绝服务。攻击者可提交精心构建的 Markdown 输入，以触发最坏情况的性能，并行发送多个请求会耗尽 CPU 资源和 PHP-FPM 进程。（CVE-2024-58382）

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

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

  - 客户端可能会向 Jetty 服务器发出 HTTP/2 请求，结果会阻止从未解除阻止的写入，最终导致所有线程被阻止，整个服务器失去响应。这是由于服务器在处理客户端发送的 RST_STREAM 帧和 GOAWAY 帧时发生争用条件所导致。此争用条件将之前设置为非空值的 HTTP2Flusher.terminated 重置为空值，从而允许条目被排入刷新程序中的队列，但该条目始终不会被处理。这些未处理的条目将取消阻断写入阻止的线程。（CVE-2026-12611）

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

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

  - 之前用于 OCaml 的 cstruct 程序包 6.3.0 错误处理索引。（CVE-2026-89087）

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

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

  - 在“multipathd”中发现一个缺陷。能够访问“multipathd”UNIX 控制套接字的本地攻击者可通过发送有效命令后停止读取回复来利用此漏洞。此操作可造成“multipathd”监听器线程阻塞，导致拒绝服务 （DoS），其中合法的进程间通信 （IPC） 操作可能挂起或超时。此问题不会导致权限升级、任意代码执行，也不会影响数据机密性或完整性。（CVE-2026-89329）

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

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

  - Hugo 是一个静态站点发生器。在 v0.123.0 之后和 v0.165.0 之前的版本中，在直接资源查找期间未丢弃父目录中的符号链接，从而允许绕过路径约束。能够在挂载的目录中（例如，在 themes/ 下的本地供应商主题中）放置符号链接的攻击者，可造成执行直接查找的函数，例如 resources。Get 和 os。ReadFile，以遵循该符号链接并读取预期项目边界之外的文件，从而在构建的站点中泄露其内容。挂载为从 GitHub 提取的 Go 模块的主题在下载时剥离了符号链接，因此不受影响，多目录遍历（例如内容/资产遍历）不受影响。此问题是 GHSA-c3wq-j5vh-68rc 和 GHSA-fw87-fv5r-9fpw 的不完整补丁后续;已在 v0.165.0 中修复。（CVE-2026-89258）

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

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

  - Net-SNMP through 在 5.9.5.2 SMUX 模块中包含拒绝服务漏洞，其中 smux_accept（） 在新接受的连接上执行未经身份验证的阻止读取而不超时。未经认证的远程客户端可连接至 SMUX 监听器且不发送任何数据，造成单线程 snmpd 主循环无限期阻断并暂停所有 SNMP 处理。（CVE-2026-89147）

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

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

  - wpa_supplicant v.2.12 之前的所有版本中的问题允许本地攻击者通过 wpa.c （CVE-2026-78807） 中基于驱动程序的 PMKSA 选择路径中缺少验证，绕过适当的网络上下文和用于 PMKSA 缓存的 AKMP 匹配

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

ID	名称	严重性
345046	Linux Distros 未修补的漏洞：CVE-2026-89772	high
345045	Linux Distros 未修补的漏洞：CVE-2026-89672	critical
345044	Linux Distros 未修补的漏洞：CVE-2026-80999	high
345043	Linux Distros 未修补的漏洞：CVE-2026-89704	high
345042	Linux Distros 未修补的漏洞：CVE-2026-89486	high
345041	Linux Distros 未修补的漏洞：CVE-2026-89498	medium
345040	Linux Distros 未修补的漏洞：CVE-2026-89611	critical
345039	Linux Distros 未修补的漏洞：CVE-2026-89752	medium
345038	Linux Distros 未修补的漏洞：CVE-2026-89756	medium
345037	Linux Distros 未修补的漏洞：CVE-2026-89487	high
345036	Linux Distros 未修补的漏洞：CVE-2026-89765	high
345035	Linux Distros 未修补的漏洞：CVE-2026-89667	high
345034	Linux Distros 未修补的漏洞：CVE-2026-89764	high
345033	Linux Distros 未修补的漏洞：CVE-2026-81000	high
345032	Linux Distros 未修补的漏洞：CVE-2026-89766	medium
345031	Linux Distros 未修补的漏洞：CVE-2026-89531	medium
345030	Linux Distros 未修补的漏洞：CVE-2026-89607	high
345029	Linux Distros 未修补的漏洞：CVE-2026-89568	medium
345028	Linux Distros 未修补的漏洞：CVE-2026-89689	critical
345027	Linux Distros 未修补的漏洞：CVE-2026-89675	critical
345026	Linux Distros 未修补的漏洞：CVE-2026-89604	medium
345025	Linux Distros 未修补的漏洞：CVE-2026-89622	high
345024	Linux Distros 未修补的漏洞：CVE-2026-89576	medium
345023	Linux Distros 未修补的漏洞：CVE-2026-89577	medium
345022	Linux Distros 未修补的漏洞：CVE-2026-80963	medium
345021	Linux Distros 未修补的漏洞：CVE-2026-89730	high
345020	Linux Distros 未修补的漏洞：CVE-2026-80932	high
345019	Linux Distros 未修补的漏洞：CVE-2026-80954	high
345018	Linux Distros 未修补的漏洞：CVE-2026-89711	high
345017	Linux Distros 未修补的漏洞：CVE-2026-89737	medium
345016	Linux Distros 未修补的漏洞：CVE-2026-89458	high
345015	Linux Distros 未修补的漏洞：CVE-2026-89670	high
345014	Linux Distros 未修补的漏洞：CVE-2026-78030	critical
345013	Linux Distros 未修补的漏洞：CVE-2026-89771	high
345012	Linux Distros 未修补的漏洞：CVE-2026-89753	medium
345011	Linux Distros 未修补的漏洞：CVE-2026-89597	high
345010	Linux Distros 未修补的漏洞：CVE-2026-89532	critical
345009	Linux Distros 未修补的漏洞：CVE-2026-89463	high
345008	Linux Distros 未修补的漏洞：CVE-2026-89633	critical
345007	Linux Distros 未修补的漏洞：CVE-2026-81010	high
345006	Linux Distros 未修补的漏洞：CVE-2026-81003	high
345005	Linux Distros 未修补的漏洞：CVE-2026-89609	high
345004	Linux Distros 未修补的漏洞：CVE-2026-80960	high
345003	Linux Distros 未修补的漏洞：CVE-2024-58382	high
345002	Linux Distros 未修补的漏洞：CVE-2026-12611	high
344909	Linux Distros 未修补的漏洞：CVE-2026-89087	high
344908	Linux Distros 未修补的漏洞：CVE-2026-89329	medium
344907	Linux Distros 未修补的漏洞：CVE-2026-89258	critical
344906	Linux Distros 未修补的漏洞：CVE-2026-89147	high
344905	Linux Distros 未修补的漏洞：CVE-2026-78807	high

检测

Nessus 的 Misc. 系列

high

critical

high

high

high

medium

critical

medium

medium

high

high

high

high

high

medium

medium

high

medium

critical

critical

medium

high

medium

medium

medium

high

high

high

high

medium

high

high

critical

high

medium

high

critical

high

critical

high

high

high

high

high

high

high

medium

critical

high

high