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

  - perf/x86/intel/uncore：修复芯片 ID 初始化和查找缺陷 在 snbep_pci2phy_map_init（） 中，当所有与 UBOX 设备关联的 CPU 离线时，nr_node_ids > 8 路径中的 uncore_device_to_die（） 可能会返回 -1。
    删除 WARN_ON_ONCE（die_id == -1） 检查有两个原因：- 当前代码中断了循环。
    这是不正确的，因为 pci_get_device（） 不保证域或总线顺序的迭代，因此在扫描期间可能会跳过更多 UBOX 设备。- 返回 -EINVAL 是不正确的，因为用 die_id == -1 标记离线总线是正常的，不应被视为错误。另外，当 NUMA 在支持 NUMA 的平台上禁用 NUMA 时，pcibus_to_node（） 返回 NUMA_NO_NODE，从而导致 uncore_device_to_die（） 为所有 PCI 设备返回 -1。因此，在 Intel SPR 和 EMR 上使用的 spr_update_device_location（） 会忽略相应的 PMON 单元，并且不会将其添加到 RB 树状结构中。使用 uncore_pcibus_to_dieid（） 修复此问题，该方法可从 UBOX GIDNIDMAP 寄存器检索拓扑，无论 Linux 中是否启用 NUMA 都可以工作。这需要在 spr_uncore_pci_init（） 中添加 snbep_pci2phy_map_init（）。仅将 uncore_device_to_die（） 保留在预期启用的 nr_node_ids > 8 情况中。（CVE-2026-43344）

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

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

  - drm/amdgpu：在等待 ioctl 中的用户输入添加上限检查 amdgpu_userq_wait_ioctl中的巨大输入值可导致 OOM，且可遭到利用。因此，根据AMDGPU_USERQ_MAX_HANDLES检查这些输入值，该值对于真正的用例来说足够大，并且可以避免 OOM。
    v2：Srini 补丁中的 squash（从提交 fcec012c664247531aed3e662f4280ff804d1476 中精选出的内容）（CVE-2026-43398）

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

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

  - net/tcp-md5：将 MAC 比较修复为常量时间 为防止时序攻击，需要在恒定时间内比较 MAC。为此请使用适当的 helper 函数。（CVE-2026-43383）

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

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

  - unshare：修复 unshare_fs（） 处理 unshare（2） 中有一个令人不快的极端情况，即我们在标记中有CLONE_NEWNS而 current->fs 根本没有被共享时;在这种情况下，copy_mnt_ns（） 传递的是 current->fs 而不是私有副本，这会导致正确性证明中出现有趣的疣] > 我猜如果私有意味着 fs->users == 1，则条件仍然可能是真。不幸的是，这比一个错综复杂的正确性证明更糟糕。考虑除 CLONE_NEWNS 之外还有 CLONE_NEWCGROUP（和 current->fs->users == 1）的情况。我们将 current->fs 传递给 copy_mnt_ns（），好吧。假设它成功并将 current->fs->{pwd，root} 翻转至新命名空间中的相应位置。现在我们继续进行 copy_cgroup_ns（），后者会失败（例如通过 -ENOMEM）。我们在 copy_mnt_ns（） 创建的命名空间上调用 put_mnt_ns（），它被销毁并且它的挂载树被溶解，但是......current->fs->root 和 current->fs->pwd 都指向现在分离的挂载。他们要固定这些漏洞，因此它不是 UAF，但它会使调用进程因 unshare（2） 失败并因 -ENOMEM _and_ 而失败，使其在分离的隔离挂载上留下 pwd 和根。最后一部分显然是一个错误。还有其他与这种混乱相关的乐趣（与 pivot_root（） 的争用，包括 pivot_root（） 和 fork（） 之间的争用），但这个很容易隔离和修复 - 将CLONE_NEWNS视为分配新fs_struct，即使它一开始就没有被共享。当然，我们可以采用诸如设置 create_new_namespaces（） 中的 copy_mnt_ns（） 调用后可能最终失败的 CLONE_NEWNS *和*一个，强制分配新fs_struct，但让我们保持简单 - copy_fs_struct（） 的成本微不足道。另一个好处是具有 CLONE_NEWNS 的 copy_mnt_ns（） *始终*会获得新分配的fs_struct，但尚未附加到任何内容。这大大简化了分析...... FWIW，该缺陷自引入 unshare（2） 以来就一直存在;（CVE-2026-43472）

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

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

  - mm/page_alloc：清除 free_pages_prepare（） 中的 page->private 多个子系统（slub、shmem、ttm 等）使用 page->private 但在释放页面之前未清除。当这些页面稍后分配为高阶页面并通过 split_page（） 拆分时，末尾页面将保留过时的页面>私有值。这会造成 swap 子系统中发生释放后使用。假设新分配的页面具有 page->>private == 0，则交换代码使用 page-private 来跟踪交换计数延续。当存在过时值时，swap_count_continued（） 会错误地假设延续列表有效，并迭代包含LIST_POISON值的未初始化的 page->lru，从而造成崩溃： KASAN：可能是范围 [0xdead000000000100-0xdead000000000107] 中的 wild-memory-access。 RIP：0010：__do_sys_swapoff+0x1151/0x1860 通过清除 free_pages_prepare（） 中的 page->private 来修复此问题，确保无论之前使用如何，所有释放的页面都处于干净状态。（CVE-2026-43303）

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

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

  - media：solo6x10：检查越界chip_id CONFIG_UBSAN_SHIFT=y 的 Clang 注意到一种情况，即有符号类型（文字 1 为 int）最终可能移动到 32 位之外，因此添加了检测（并且由于通过内联看到双重 is_tw286x（） 调用），Clang 确定第二个问题现在一定为未定义的行为并省略函数 [1] 的其余部分。这是 Clang 的一个已知问题（仍在处理中），但我们可以通过实际检查现有的最大芯片 ID 来避免整个问题，并且现在完全没有添加运行时检测，因为已知一切都在界内。
    此外，即使没有明确的边界检查，也请使用位移的无符号值删除检测。[hverkuil：修复is_tw286x的 checkpatch 警告]（CVE-2026-43316）

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

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

  - drm/amdgpu：修复 VM 获取中的释放后使用争用 将非原子 vm->process_info 分配替换为 cmpxchg（），以防止父/子进程共享一个drm_file在 fork（） 之后尝试获取同一 VM 时发生争用。（从提交 c7c573275ec20db05be769288a3e3bb2250ec618 中精选出的内容）（CVE-2026-43370）

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

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

  - btrfs：当 fs 翻转 btrfs_repair_io_failure（） 中的 RO 时，不 ASSERT（） [缺陷] 有缺陷报告指出，当 btrfs 在关键路径中发生 ENOSPC 错误时，btrfs 会翻转 RO（这部分是预期的，尽管仍需要解决 ENOSPC 缺陷）。问题在于在 RO 翻转之后，如果存在待定的读取修复，我们可以点击 btrfs_repair_io_failure（） 中的 ASSERT（），如下所示： BTRFS 信息 （设备 vdc）：重新定位块群组 30408704 标记元数据|raid1 ------------[ 切中 ]------------ BTRFS：
    事务已中止（错误 -28） 警告：fs/btrfs/extent-tree.c：3235 at
    __btrfs_free_extent.isra.0+0x453/0xfd0， CPU#1： btrfs/383844 模块链接于： kvm_intel kvm irqbypass [...] ---[ end trace 00000000000000000 ]--- BTRFS 信息（设备 vdc 状态 EA）：平衡期间出现 2 个 enospc 错误 BTRFS 信息（设备 vdc 状态 EA）：平衡：以状态结束： -30 BTRFS 错误（设备 vdc 状态 EA）：逻辑 30556160 镜像上的父 transid 验证失败 2 想要 8 发现 6 BTRFS 错误（设备 vdc 状态 EA）： bdev /dev/nvme0n1 错误：WR 0、RD 0、刷新 0、损坏 10、gen 0 [...] 断言失败：
    !（fs_info->sb->s_flags &; SB_RDONLY） ：： 0， in fs/btrfs/bio.c：938 ------------[ cut here ]------------断言失败： ！（fs_info->sb->s_flags &; SB_RDONLY） ：： 0，fs/btrfs/bio.c：938 中的内核缺陷 fs/btrfs/bio.c：938！Oops： invalid opcode： 0000 [#1] SMP NOPTI CPU： 0 UID： 0 PID： 868 Comm： kworker/u8：13 受感染： G W N 6.19.0-rc6+ #4788 PREEMPT（full） 受感染： [W]=WARN， [N]=TEST 硬件名称： QEMU Standard PC （Q35 + ICH9， 2009）， BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 工作队列： btrfs-endio simple_end_io_work RIP： 0010：btrfs_repair_io_failure.cold+0xb2/0x120 RSP： 0000：ffffc90001d2bcf0 EFLAGS：
    00010246 RAX：0000000000000051 RBX：0000000000001000 RCX：0000000000000000 RDX：00000000000000000 RSI：
    ffffffff8305cf42 RDI： 000000000ffffffff RBP： 0000000000000002 ： 000000000fffeffff R09： ffffffff837fa988 R10： ffffffff8327a9e0 R11： 6f69747265737361 R12： ffff88813018d310 R13： ffff888168b8a000R14：R08
    ffffc90001d2bd90 R15：ffff88810a169000 FS：0000000000000000（0000） GS：ffff8885e752c000（0000） knlGS：000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 ------------[ cut here]------------ [CAUSE] 测试用例 btrfs/124 期间发生 -ENOSPC 错误的原因仍然未知，不过众所周知，仍有元数据可过度使用但无法正确履行的情况，因此，如果在关键路径中遇到此类 ENOSPC 错误， 我们别无选择，只能中止当前的交易。这会将 fs 标记为只读。问题出在 btrfs_repair_io_failure（） 路径内部，我们要求 fs 不得挂载为只读。这通常没问题，但如果我们在进行读取-修复的同时，fs 由于严重错误而翻转 RO，我们可以输入 btrfs_repair_io_failure（），并将超级块设置为只读，从而触发上述崩溃。[修复]如果 fs 已经是只读，只需将 ASSERT（） 替换为正确的返回函数即可。（CVE-2026-43299）

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

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

  - libceph：将 u32 用于 ceph_monmap_decode（） 中的非负值 此修补程序可修复不必要的隐式转换，这些转换会更改 ceph_monmap_decode（） 中的blob_len和num_mon符号。目前 blob_len 和 num_mon 是（已签名的）int 变量。它们用于保存始终为非负值并在 ceph_decode_32_safe（） 中赋值的值，该值用于赋值 u32 值。这两个变量随后都用作无符号值，num_mon 的值进一步分配给类型为 u32 的 monmap->num_mon。因此，两个变量都应为 u32 类型。这与num_mon尤其相关。如果从传入消息读取的值很大，它会被解释为负值，num_mon > CEPH_MAX_MON检查不会捕获它。这会导致尝试为 monmap 分配非常大的内存区块，并且很有可能会失败。在这种情况下，将执行不必要的内存分配尝试，并返回 -ENOMEM 而非 -EINVAL。（CVE-2026-43405）

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

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

  - i3c：mipi-i3c-hci：修复 DMA 环出列中的争用 HCI DMA 出列路径 （hci_dma_dequeue_xfer（）） 可能会针对大约在同一时间超时的多个传输调用。但是，该函数不是序列化的，并且可能与自身争用。当出现超时时，hci_dma_dequeue_xfer（） 会停止环，处理不完整的传输，然后重新启动环。如果另一个超时触发了对同一函数的并行调用，则这两个实例可能会相互干扰 - 在意外时间停止或重新启动环。添加互斥体，以便相对于其自身对 hci_dma_dequeue_xfer（） 进行序列化。
    (CVE-2026-43353)

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

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

  - netfilter：nfnetlink_cthelper：修复 nfnl_cthelper_dump_table（） 中的 OOB 读取 nfnl_cthelper_dump_table（） 具有跳转到 for 循环正文内的标签的“goto restart”。在转储轮次之间删除 cb->args[1] 中保存的最后一个辅助函数时，每个条目都会未通过 （cur ！= last） 检查，因此从不清除 cb->args[1]。for 循环以 cb->args[0] == nf_ct_helper_hsize 结束，“goto restart”跳回循环正文绕过边界检查，进而造成 nf_ct_helper_hash[nf_ct_helper_hsize] 上发生 8 字节越界读取。“goto restart”块的预期是在找不到最后一个存储桶时重新遍历当前存储段，但该块被放置在 for 循环之后而不是在其内部。将区块移动到 for 循环正文中，以便仅当 cb->args[0] 仍在界内时才会重新启动。
    缺陷：KASAN：在 nfnl_cthelper_dump_table+0x9f/0x1b0 中存在 slab-out-ofbound 按任务 poc_cthelper/131 在地址 ffff888104ca3000 读取的读取大小为 8 调用跟踪：nfnl_cthelper_dump_table+0x9f/0x1b0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 sock_recvmsg+0xde/0xf0 __sys_recvfrom+0x150/0x200
    __x64_sys_recvfrom+0x76/0x90 do_syscall_64+0xc3/0x6e0 按任务 1 分配：
    __kvmalloc_node_noprof+0x21b/0x700 nf_ct_alloc_hashtable+0x65/0xd0 nf_conntrack_helper_init+0x21/0x60 nf_conntrack_init_start+0x18d/0x300 nf_conntrack_standalone_init+0x12/0xc0 （CVE-2026-43450）

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

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

  - Bluetooth：SMP：在构建配对响应之前强制响应程序 MITM 要求 smp_cmd_pairing_req（） 目前会在强制执行本地BT_SECURITY_HIGH要求之前构建来自发起程序auth_req的配对响应。如果发起程序省略SMP_AUTH_MITM，即使本地端仍需要 MITM，响应也可以省略。然后，tk_request（） 会看到无SMP_AUTH_MITM的认证值，并可能会选择JUST_CFM，造成方法选择与响应器已强制执行的配对策略不一致。当本地端需要高安全性时，首先验证是否可以通过 IO 功能实现 MITM，然后在 rsp.auth_req 和 auth 的响应中强制SMP_AUTH_MITM。这样会使响应程序认证位和后续方法选择保持一致。（CVE-2026-43334）

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

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

  - cgroup：修复任务迁移与迭代之间的争用 当任务迁移出css_set时，cgroup_migrate_add_task（） 首先通过以下方式将其从 cset->tasks 移动到 cset->mg_tasks：
    list_move_tail（&task->cg_list， &cset->mg_tasks）;如果css_task_iter当前具有指向此任务的 it->task_pos，则 css_set_move_task（） 会调用 css_task_iter_skip（） 以保持迭代器有效。但是，由于任务已移动到 ->mg_tasks，因此迭代器相对于mg_tasks列表而不是原始任务列表向前推进。因此，可通过迭代跳过 cset->tasks 上的其余任务，以及 cset->mg_tasks 上已排入队列的任务。通过在断开 task->cg_list 与 cset->tasks 的链接之前调用 css_set_skip_task_iters（），来修复此问题。这会将所有活动迭代器推进到 cset->tasks 上的下一个任务，因此即使同时迁移任务，迭代也会正确继续。这场比赛在实践中很难在没有乐器的情况下击球，但可以通过人为减慢速度来重现 cgroup_procs_show（）。例如，在 Android 设备上，可以添加一个临时的 /sys/kernel/cgroup/cgroup_test 旋钮以将延迟注入 cgroup_procs_show（），然后：1） 生成三个长时间运行的任务（PID 101、102、103）。2） 创建一个测试 cgroup 并将任务移动到其中。3） 通过 /sys/kernel/cgroup/cgroup_test 启用大延迟。4） 在一个 shell 中，从测试 cgroup 中读取 cgroup.procs。5） 在延迟窗口中，通过将 PID 102 写入到不同的 cgroup.procs 文件，在另一个 shell 中迁移 PID。在此设置下，cgroup.procs 可间歇性地仅显示 PID 101，同时跳过 PID 103。迁移完成后，再次读取文件会按预期显示所有任务。请注意，此更改不允许删除 css_set_move_task（） 中现有的 css_set_skip_task_iters（） 调用。cgroup_migrate_add_task（） 中的新调用仅处理当任务仍在 cset->tasks 上时与迁移争用的迭代器。迭代器也可以在将任务移动到 cset->mg_tasks 后启动。如果从 css_set_move_task（） 中删除 css_set_skip_task_iters（），此类迭代器可一直task_pos指向正在迁移的任务，从而导致目标css_set上的 css_task_iter_advance（） 出现故障，直至崩溃或无限循环。迁移和迭代之间的争用窗口非常小，css_task_iter不在热路径上。在最糟糕的情况下，当迭代器位于迁移进程的第一个线程上时，cgroup_migrate_add_task（） 可能不得不通过 css_set_skip_task_iters（） 跳过多个任务。但是，只有在迁移和迭代实际争用时才会发生这种情况，所以与此处提供的正确性补丁相比，对性能的影响可以忽略不计。(CVE-2026-43439)

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

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

  - ALSA：pcm：修复 snd_pcm_drain（） 中链接流运行时的释放后使用 在漏循环中，将本地变量“runtime”重新分配给链接流的运行时（第 2157 行的 runtime = s->runtime）。在第 2169 行释放流锁后，代码访问 runtime->no_period_wakeup、runtime->rate 和 runtime->buffer_size（行 2170-2178），所有这些都引用链接流的运行时，而没有任何保护其生命周期的锁或引用计数。链接流的 fd 上的并发 close（） 触发 snd_pcm_release_substream（） snd_pcm_drop（） pcm_release_private（） snd_pcm_unlink（） snd_pcm_detach_substream（） kfree（runtime）。当漏路径取消引用过时指针时，没有同步会阻止 kfree（runtime） 完成。修复方法为在仍保留流锁定的同时将所需的运行时字段（no_period_wakeup、速率buffer_size）缓存到本地变量中，并在释放锁定后使用缓存值。（CVE-2026-43437）

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

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

  - drm/amd/display：修复 HWSS 快速路径中 DMUB HW 锁定的不匹配解锁 [原因] 关于是否需要使用 DMUB HW 锁定的评估与是否需要解锁不同，这会导致在没有 FAMS 支持的 ASIC 中使用快速路径时挂起。[如何]存储一个指示我们是否应该使用锁的标志，并使用相同的标志来指定是否需要解锁。（CVE-2026-43305）

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

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

  - scsi：storvsc：修复原子启动 PREEMPT_RT 时的计划 这解决了在 Hyper-V 上启用 PREEMPT_RT 的情况下运行时发生的以下崩溃和锁定：[ 415.140818] 缺陷：原子时的计划：stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO：lockdep 已关闭。 [ 415.140823] 模块链接于：
    intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_通用hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common [ 415.140846] Preemption 禁用：[ 415.140847]<ffffffffc0656171> [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140854] CPU：8 UID：0 PID：1048 通信： stress-ng-iomix 未受感染 6.19.0-rc7 #30 PREEMPT_{RT，（full）} [ 415.140856] 硬件名称：
    Microsoft Corporation 虚拟机/虚拟机，BIOS Hyper-V UEFI 版本 v4.1 2024 年 9 月 4 日 [415.140857] 调用跟踪：[ 415.140861] [ 415.140861<TASK> ] ？ storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc] [ 415.140863] dump_stack_lvl+0x91/0xb0 [ 415.140870] __schedule_bug+0x9c/0xc0 [ 415.140875]
    __schedule+0xdf6/0x1300 [ 415.140877] ？ rtlock_slowlock_locked+0x56c/0x1980 [ 415.140879] ？ rcu_is_watching+0x12/0x60 [ 415.140883] schedule_rtlock+0x21/0x40 [ 415.140885] rtlock_slowlock_locked+0x502/0x1980 [ 415.140891] rt_spin_lock+0x89/0x1e0 [ 415.140893] hv_ringbuffer_write+0x87/0x2a0 [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0 [ 415.140900] ？ rcu_is_watching+0x12/0x60 [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc] [ 415.140904] ？HARDIRQ_verbose+0x10/0x10 [ 415.140908] ？ __rq_qos_issue+0x28/0x40 [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod] [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0 [ 415.140928] blk_mq_issue_direct+0x87/0x2b0 [415.140931] blk_mq_dispatch_queue_requests+0x120/0x440 [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0 [415.140935] __blk_flush_plug+0xf4/0x150 [ 415.140940] __submit_bio+0x2b2/0x5c0 [ 415.140944] ？ submit_bio_noacct_nocheck+0x272/0x360 [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360 [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4] [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4] [ 415.141018] ？
    __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4] [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4] [415.141060] generic_perform_write+0x14e/0x2c0 [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4] [415.141083] vfs_write+0x2ca/0x570 [ 415.141087] ksys_write+0x76/0xf0 [ 415.141089] do_syscall_64+0x99/0x1490 [ 415.141093] ？ rcu_is_watching+0x12/0x60 [ 415.141095] ？ finish_task_switch.isra.0+0xdf/0x3d0 [ 415.141097] ？ rcu_is_watching+0x12/0x60 [ 415.141098] ？ lock_release+0x1f0/0x2a0 [ 415.141100] ？ rcu_is_watching+0x12/0x60 [ 415.141101] ?finish_task_switch.isra.0+0xe4/0x3d0 [ 415.141103] ？ rcu_is_watching+0x12/0x60 [ 415.141104] ？
    __schedule+0xb34/0x1300 [ 415.141106] ？ hrtimer_try_to_cancel+0x1d/0x170 [ 415.141109] ？ do_nanosleep+0x8b/0x160 [ 415.141111] ？ hrtimer_nanosleep+0x89/0x100 [ 415.141114] ？
    __pfx_hrtimer_wakeup+0x10/0x10 [ 415.141116] ？ xfd_validate_state+0x26/0x90 [ 415.141118] ？ rcu_is_watching+0x12/0x60 [ 415.141120] ？ do_syscall_64+0x1e0/0x1490 [ 415.141121] ？ do_syscall_64+0x1e0/0x1490 [ 415.141123] ？ rcu_is_watching+0x12/0x60 [ 415.141124] ？ do_syscall_64+0x1e0/0x1490 [ 415.141125] ？ do_syscall_64+0x1e0/0x1490 [ 415.141127] ？ irqentry_exit+0x140/0 ---truncated--- （CVE-2026-43475）

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

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

  - USB： usbtmc：将 usb_bulk_msg_killable（） 与用户指定的超时一起使用 usbtmc 驱动程序接受用户在 ioctl 命令中指定的超时值，并将这些超时用于某些 usb_bulk_msg（） 调用。
    由于用户可以指定任意长超时并且 usb_bulk_msg（） 使用无法终止的等待，因此请改为调用 usb_bulk_msg_killable（） 以避免用户无限期挂起内核线程的可能性。
    (CVE-2026-43429)

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

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

  - drm：帐户属性 blob 分配给 memcg DRM_IOCTL_MODE_CREATEPROPBLOB允许用户空间分配由内核内存支持的任意大小的属性 blob。目前，blob 数据分配并未计入分配进程的内存 cgroup，这使得非特权用户能够触发无限的内核内存消耗，并可能导致系统范围的 OOM。使用GFP_KERNEL_ACCOUNT标记属性 blob 数据分配，以便将内存正确地充值到调用方的 memcg。这可确保现有 cgroup 内存限制适用，并防止不受控制的内核内存增长，而不会引入额外的策略或按文件的限制。（CVE-2026-43287）

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

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

  - rapidio：将 rio_free_net（） 替换为 rio_scan_alloc_net（） 中的 kfree（） 当 idtab 分配失败时，net 尚未向 rio_add_net（） 注册，因此 kfree（net） 足足以释放内存。将 mport->net 设置为 NULL 以避免悬摆指针。（CVE-2026-43295）

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

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

  - serial：caif：保持 ldisc_open 和 ser_release 中的 tty->link 引用 当 caif_serial 的 TX 路径调用 tty_write_room（） 时，复制器会在 pty_write_room（） 中触发 KASAN slab-after-free-use-later-free。错误访问发生在 tty->link->port 上。在 caif_serial 行规范的生命周期内保持 tty->link 上的额外 kref：在 ldisc_open（） 中取得该 kref 然后在 ser_release（） 中丢弃，同时在 ldisc_open（） 错误路径中丢弃。应用此更改后，复制器不会再在我的测试中触发 UAF。
    (CVE-2026-43458)

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

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

  - btrfs：为 qgroup ioctls 预留足够的事务项目当前 qgroup ioctl 不预留任何空间，它们只是进行事务加入，既不为配额树更新预留任何空间，也不会为更新配额树时生成的延迟 refs 预留任何空间。配额根使用全局区块预留，这在大多数情况下都没问题，因为我们不期望配额根进行大量更新，或者太接近 -ENOSPC，以致于其他关键元数据更新需要使用全局预留。
    但是，这并不是最佳选择，因为未预留适当的空间可能会导致事务中止，原因是未为延迟的 refs 预留空间，然后滥用全局区块预留。例如，以下复制器（不太可能模拟任何真实世界的用例，但只是为了说明问题）在运行延迟的 refs 时，由于 -ENOSPC 触发此类事务中止：$ cat test.sh #！/bin/bash DEV=/dev/nullb0 MNT=/mnt/nullb0 umount $DEV &> /dev/null # 将设备限制为 1G，以便以更快的速度重现该问题。 mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT fallocate -l 800M $MNT/filler btrfs 配额启用 $MNT 对于 （（i = 1; i <= 400000; i++））;do btrfs qgroup create 1/$i $MNT done umount $MNT 运行此操作时，我们可以在 dmesg/syslog 中看到事务已中止：
    [436.490] BTRFS 错误 （device nullb0）： 无法为逻辑30408704 num_bytes 16384 类型 176 操作 1 ref_mod 1 运行延迟的 ref [436.493] ------------[ cut here ]------------ [436.494] BTRFS： 事务已中止（错误 -28） [436.495] WARNING： fs/btrfs/extent-tree.c：2247 at btrfs_run_delayed_refs+0xd9/0x110 [btrfs]， CPU#4： umount/2495372 [436.497] 链接的模块：btrfs 循环 （...）[436.508] CPU：4 UID：0 PID：
    2495372 通信：umount 受感染：G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT（full） [436.510] 受感染：[W]=WARN [436.511] 硬件名称：QEMU Standard PC （i440FX + PIIX， 1996），BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 2014 年 4 月 1 日 [436.513] RIP：
    0010：btrfs_run_delayed_refs+0xdf/0x110 [btrfs] [436.514] 代码：0f 82 ea （...）[436.518] RSP：
    0018：ffffd511850b7d78 EFLAGS：00010292 [436.519] RAX：00000000ffffffe4 RBX：ffff8f120dad37e0 RCX：
    0000000002040001 [436.520] RDX：0000000000000002 RSI：00000000ffffffe4 RDI：ffffffffc090fd80 [436.522] RBP：0000000000000000 R08：0000000000000001 R09：ffffffffc04d1867 [436.523] R10：ffff8f18dc1fffa8 R11：
    0000000000000003 ： ffff8f173aa89400 [436.524] R13： 000000000000000 R14： ffff8f173aa89400R15R12：
    0000000000000000 [436.526] FS： 00007fe59045d840（0000） GS：ffff8f192e22e000（0000） knlGS：000000000000000 [436.527] CS：0010 DS： 0000 ES： 0000 CR0： 0000000080050033 [436.528] CR2： 00007fe5905ff2b0 CR3：
    000000060710a002 CR4： 00000000000370ef0 [436.530] 调用跟踪： [436.530] [436.530] <TASK> btrfs_commit_transaction+0x73/0xc00 [btrfs] [436.531] ？ btrfs_attach_transaction_barrier+0x1e/0x70 [btrfs] [436.532] sync_filesystem+0x7a/0x90 [436.533] generic_shutdown_super+0x28/0x180 [436.533] kill_anon_super+0x12/0x40 [436.534] btrfs_kill_super+0x12/0x20 [btrfs] [436.534] deactivate_locked_super+0x2f/0xb0 [436.534] cleanup_mnt+0xea/0x180 [436.535] task_work_run+0x58/0xa0 [436.535] exit_to_user_mode_loop+0xed/0x480 [436.536] ？ __x64_sys_umount+0x68/0x80 [436.536] do_syscall_64+0x2a5/0xf20 [436.537] entry_SYSCALL_64_after_hwframe+0x76/0x7e [436.537] RIP：
    0033：0x7fe5906b6217 [436.538] 代码：0d 00 f7 （...）[436.540] RSP：002b：00007ffcd87a61f8 EFLAGS：00000246 ORIG_RAX：0000000000000000a6 [436.541] RAX：00000000000000000 RBX：00005618b9ecadc8 RCX：00007fe5906b6217 [436.541] RDX：000000000000000000 RSI：0000000000000000 RDI：00005618b9ecb100 [436.542] RBP：
    00000000000000000 R08： 00007ffcd87a4fe0 R09： 000000000ffffffff [436.544] R10： 0000000000000103 R11：
    ---truncated--- (CVE-2026-43338)

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

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

  - sched_ext：通过将等待到平衡回调SCX_KICK_WAIT使用 smp_cond_load_acquire（） 来修复kick_cpus_irq_workfn SCX_KICK_WAIT死锁，直到目标 CPU 的kick_sync前进。由于 irq_work 在 hardirq 上下文中运行，等待的 CPU 无法重新计划，并且其自己的kick_sync永远不会前进。如果多个 CPU 形成一个等待周期，则所有 CPU 都会死锁。将 kick_cpus_irq_workfn（） 中的忙碌等待替换为 resched_curr（） 以强制 CPU 通过 do_pick_task_scx（），这会将平衡回调排队以执行等待。平衡回调会终止 rq 锁定并按照 sched_core_balance（） 模式启用 IRQ，以便 CPU 可以在等待时处理 IPI。本地 CPU 的kick_sync在进入 do_pick_task_scx（） 时推进，并在等待期间持续推进，确保任何开始等待我们的 CPU 都能看到进步并且不会形成循环依赖关系。（CVE-2026-43326）

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

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

  - drm/v3d：设置 DMA 段大小以避免调试警告 在启用了 CONFIG_DMA_API_DEBUG 的情况下使用 V3D 渲染时，内核偶尔会报告段大小不匹配。这是因为“max_seg_size”并未设置。内核默认为 64K。 将“max_seg_size”设置为最大值将阻止“debug_dma_map_sg（）”抱怨 V3D 段长度的过度映射。DMA-API：v3d 1002000000.v3d：映射 sg 段比设备声明的支持时间长 [len=8290304] [max=65536] 警告：CPU：0 PID：493 at kernel/dma/debug.c：1179 debug_dma_map_sg+0x330/0x388 CPU：0 UID：0 PID：493 通信：Xorg 未受感染 6.12.53-yocto-standard #1 硬件名称：Raspberry Pi 5 Model B Rev 1.0 （DT） 状态：60400009 （nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--） pc： debug_dma_map_sg+0x330/0x388 LR： debug_dma_map_sg+0x330/0x388 SP： ffff8000829a3ac0 x29： ffff8000829a3ac0 x28： 0000000000000001 x27： ffff8000813fe000 x26： ffffc1ffc0000000 x25： ffff00010fdeb760 x24： 0000000000000000 x23： ffff8000816a9bf0 x22： 0000000000000001 x21：
    0000000000000002 x20： 0000000000000002 x19： ffff00010185e810 x18： ffffffffffffffffff x17： 69766564206e6168 x16： 74207265676e6f6c x15： 20746e656d676573 x14： 20677320676e6970 x13： 5d34303334393134 x12：
    00000000000000000 x11： 00000000000000000c0 x10： 00000000000009c0 x9 ： ffff8000800e0b7c x8 ： ffff00010a315ca0 x7 ： ffff8000816a5110 x6 ： 0000000000000001 x5： 000000000000002b x4 ： 0000000000000002 x3 ：
    0000000000000008 x2 ： 0000000000000000 x1 ： 000000000000000 x0 ： ffff00010a315280 调用跟踪：
    debug_dma_map_sg+0x330/0x388 __dma_map_sg_attrs+0xc0/0x278 dma_map_sgtable+0x30/0x58 drm_gem_shmem_get_pages_sgt+0xb4/0x140 v3d_bo_create_finish+0x28/0x130 [v3d] v3d_create_bo_ioctl+0x54/0x180 [v3d] drm_ioctl_kernel+0xc8/0x140 drm_ioctl+0x2d4/0x4d8 （CVE-2026-43302）

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

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

  - smb：客户端：读取模式位之前需要完整的 NFS 模式 SID parse_dacl（） 将 ACE SID 匹配sid_unix_NFS_mode视为 NFS 模式 SID，并读取 sid.sub_auth[2] 以恢复模式位。这假设 ACE 带有三个子机构，但 compare_sids（） 仅比较 min（a， b） 子机构。恶意服务器可返回 num_subauth = 2 且 sub_auth[] = {88， 3} 的 ACE，该 ACE 仍匹配 sid_unix_NFS_mode，然后驱动 sub_auth[2] 读取超出 ACE 末尾四个字节。需要 num_subauth >= 3，然后才能将 ACE 视为 NFS 模式 SID。这会将补丁保留在特殊 SID 模式路径的本地位置，而不改变 cifsacl 其余部分的 compare_sids（） 语义。（CVE-2026-43350）

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

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

  - rxrpc、afs：修复 rxrpc_kernel_lookup_peer（） 之后缺少的错误指针检查 rxrpc_kernel_lookup_peer（） 除了返回 NULL 之外还可返回错误指针，因此仅检查 NULL 是不够的。通过以下方式修复此问题：（1） 更改 rxrpc_kernel_lookup_peer（） 以在分配失败时返回 -ENOMEM 而不是 NULL。（2） 使 afs 中的调用程序使用 IS_ERR（） 和 PTR_ERR（） 传递返回的错误代码。（CVE-2026-43463）

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

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

  - 已修复 Linux 内核中的下列漏洞：libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header. (CVE-2026-43406)

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

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

  - fast-xml-parser 允许用户在不基于 C/C++ 的库或回调的情况下从 JS 对象处理 XML。
    低于版本 5.7.0、XMLBuilder 在从 JavaScript 对象构建 XML 时不会转义注释内容中的 --> 序列或 ]]> CDATA 部分中的序列。当用户控制的数据流入注释或 CDATA 元素时，这允许 XML 注入，导致 XSS、SOAP 注入或数据操纵。此问题已在版本中修复 5.7.0。(CVE-2026-41650)

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

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

  - usb：renesas_usbhs：修复设备删除期间 ISR 中的释放后使用 在 usbhs_remove（） 中，仍在注册中断处理程序 （usbhs_interrupt） 时，驱动程序会释放资源（包括管道数组）。如果中断在 usbhs_pipe_remove（） 之后但在驱动程序完全解除绑定之前触发，则 ISR 可能访问已释放的内存，从而导致释放后使用。通过在释放资源之前调用 devm_free_irq（） 来修复此问题。这可确保在调用 usbhs_pipe_remove（） 之前，中断处理程序被禁用并同步（等待任何正在运行的 ISR 完成）。（CVE-2026-43426）

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

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

  - drm/amdgpu：修复 amdgpu_dma_buf_move_notify 中的同步处理 使 dmabuf 失效将影响共享 BO 的其他用户。在进程 A 移动 BO 的情况下，它需要将移动通知进程 B，并且进程 B 需要更新其页表。提交操作修复了因使用票证而造成的同步缺陷：它使amdgpu_vm_handle_moved表现得好像立即更新页表是正确的，但在这种情况下并非如此。例如，在不支持 P2P PCI 的系统上，2 个 GPU 和 glxgears 在 GPU0 上运行，Xorg 在 GPU1 上运行： glxgears：从 GPU0 导出线性缓冲区并使用 GPU1 导入 将帧渲染提交到 GPU0 提交 tiled->linear blit Xorg：线性缓冲区的副本 作业的顺序为： drm_sched_job_run # GPU0，帧渲染 drm_sched_job_queue # GPU0，blit drm_sched_job_done # GPU0，帧渲染 drm_sched_job_run # GPU0，blit 移动用于 GPU1 访问的线性缓冲区 # amdgpu_dma_buf_move_notify -> update pt # GPU0 此时，GPU0 上的 blit 作业仍在运行，并可能产生页面错误。（CVE-2026-43318）

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

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

  - ceph：修复 ceph_mdsc_build_path（） 中的内存泄漏 向未释放 __getname（） 获取的路径指针的错误代码路径添加 __putname（） 调用。如果此指针的所有权未通过 path_info.path 传递给调用者，函数必须先释放该指针，然后才能返回。（CVE-2026-43419）

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

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

  - ASoC：soc-core：删除 DAI 和小组件之前刷新延迟的工作 如果打开 PCM 流时声卡未绑定，则从 close_delayed_work 工作队列处理程序调用的 snd_soc_dapm_stream_event（） 中可发生释放后使用。在取消绑定期间，snd_soc_unbind_card（） 刷新延迟的工作，然后调用 soc_cleanup_card_resources（）。在清理过程中，snd_card_disconnect_sync（） 释放所有 PCM 文件描述符，生成的 PCM 关闭路径可调用 snd_soc_dapm_stream_stop（），后者会以pmdown_time定时器延迟来计划新的延迟工作。由于这发生在 snd_soc_unbind_card（） 中的刷新之后，因此不会捕获新工作。然后，soc_remove_link_components（） 会在此工作触发前释放 DAPM 小组件，从而导致释放后使用。soc_free_pcm_runtime（） 中的现有刷新也无济于事，因为它是在 soc_remove_link_components（） 释放小组件之后运行的。在 soc_cleanup_card_resources snd_card_disconnect_sync（） 之后以及 soc_remove_link_dais（） 和 soc_remove_link_components（） 之前（拆除延迟工作访问的结构）的 （） 中以及 （） 和 （） 之前，添加刷新。（CVE-2026-43459）

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

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

  - scsi：ufs：core：修复 ufshcd_add_command_trace（） 中可能的空指针取消引用 内核日志会显示 ufshcd_add_command_trace 中发生崩溃，这是因为访问 hwq->id 时发生空指针取消引用所导致。
    如果 ufshcd_mcq_req_to_hwq（） 返回 NULL，则可能会发生这种情况。此修补程序在访问 hwq 的 id 字段之前添加了对 hwq 的 NULL 检查，以防止内核崩溃。内核日志摘录： [<ffffffd5d192dc4c>] notify_die+0x4c/0x8c [<ffffffd5d1814e58>] __die+0x60/0xb0 [<ffffffd5d1814d64>] die+0x4c/0xe0 [<ffffffd5d181575c>] die_kernel_fault+0x74/0x88 [<ffffffd5d1864db4>] __do_kernel_fault+0x314/0x318 [<ffffffd5d2a3cdf8>] do_page_fault+0xa4/0x5f8 [<ffffffd5d2a3cd34>] do_translation_fault+0x34/0x54 [<ffffffd5d1864524>] do_mem_abort+0x50/0xa8 [<ffffffd5d2a297dc>] el1_abort+0x3c/0x64 [<ffffffd5d2a29718>] el1h_64_sync_handler+0x44/0xcc [<ffffffd5d181133c>] el1h_64_sync+0x80/0x88 [<ffffffd5d255c1dc>] ufshcd_add_command_trace+0x23c/0x320 [<ffffffd5d255bad8>] ufshcd_compl_one_cqe+0xa4/0x404 [<ffffffd5d2572968>] ufshcd_mcq_poll_cqe_lock+0xac/0x104 [<ffffffd5d11c7460>] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod] [<ffffffd5d19ab92c>] __handle_irq_event_percpu+0xc8/0x348 [<ffffffd5d19abca8>] handle_irq_event+0x3c/0xa8 [<ffffffd5d19b1f0c>] handle_fasteoi_irq+0xf8/0x294 [<ffffffd5d19aa778>] generic_handle_domain_irq+0x54/0x80 [<ffffffd5d18102bc>] gic_handle_irq+0x1d4/0x330 [<ffffffd5d1838210>] call_on_irq_stack+0x44/0x68 [<ffffffd5d183af30>] do_interrupt_handler+0x78/0xd8 [<ffffffd5d2a29c00>] el1_interrupt+0x48/0xa8 [<ffffffd5d2a29ba8>] el1h_64_irq_handler+0x14/0x24 [<ffffffd5d18113c4>] el1h_64_irq+0x80/0x88[<ffffffd5d2527fb4>] arch_local_irq_enable+0x4/0x1c [<ffffffd5d25282e4>] cpuidle_enter+0x34/0x54 [<ffffffd5d195a678>] do_idle+0x1dc/0x2f8 [<ffffffd5d195a7c4>] cpu_startup_entry+0x30/0x3c [<ffffffd5d18155c4>] secondary_start_kernel+0x134/0x1ac [<ffffffd5d18640bc>]
    __secondary_switched+0xc4/0xcc （CVE-2026-43471）

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

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

  - octeontx2-af：通过禁用粘着 NIX SQ 管理器粘滞模式解决 SQM/PSE 停止，已知在多个 SQ 共享一个 SMQ 并同时传输时造成停止。此外，PSE 还可能在粘性和非粘性传输之间的转换上发生死锁。当某些条件时钟被关控时，还会出现一个信用下降问题。通过以下方法解决这些硬件勘误表： - 禁用 SQM 粘滞操作： - 清除 TM6（第 15 位） - 清除 TM11 （第 14 位） - 禁用可死锁 PSE 的粘滞非粘滞转换路径： - 清除 TM5（第 23 位） - 通过保持启用控制流时钟防止信用额度下降：- 设置 TM9（第 21 位） 通过NIX_AF_SQM_DBG_CTL_STATUS应用这些更改。通过此配置，SQM/PSE 在负载下保持向前进度，而不会造成信用损失，但代价是禁用粘性优化。（CVE-2026-43296）

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

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

  - net/mlx5e：修复错误 CQE SQ 恢复时的 DMA FIFO 不同步 在发生 TX 错误 CQE 时，会触发恢复流，mlx5e_reset_txqsq_cc_pc（） 将 dma_fifo_cc 重置为 0 而不是 dma_fifo_pc，从而使 DMA FIFO 生产者和使用者失去同步。恢复后，生产者将新的 DMA 条目推送到旧dma_fifo_pc，而使用者则从位置 0 读取。这导致我们在恢复之前取消映射过时的 DMA 地址。
    DMA FIFO 是一个纯粹的软件构造，没有硬件对应物。在重置时，所有 WQE 都已刷新，因此dma_fifo_cc已经等于 dma_fifo_pc。无需重置任何一个计数器，类似于不影响 pc/cc skb_fifo方式。删除“dma_fifo_cc = 0”重置。这修复了以下问题 WARNING： WARNING： CPU： 0 PID： 0 at drivers/iommu/dma-iommu.c：1240 iommu_dma_unmap_page+0x79/0x90 链接的模块： mlx5_vdpa vringh VDPA 绑定mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangleip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter叠加 zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [上次卸载： nf_tables] CPU：0 UID：0 PID：0 通信：swapper/0 未受感染 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 硬件名称：QEMU 标准 PC（Q35 + ICH9,2009 年），BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 2014 年 4 月 1 日 RIP：0010：iommu_dma_unmap_page+0x79/0x90 代码：2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 415d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 呼叫跟踪：
    <IRQ> ?__warn+0x7d/0x110 ？iommu_dma_unmap_page+0x79/0x90 ？report_bug+0x16d/0x180 ？handle_bug+0x4f/0x90 ？exc_invalid_op+0x14/0x70 ？asm_exc_invalid_op+0x16/0x20 ？iommu_dma_unmap_page+0x79/0x90 ？iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core]
    __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ？mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ？notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 asm_common_interrupt </IRQ> <TASK> +0x22/0x40 （CVE-2026-43466）

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

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

  - iio：gyro：mpu3050-core：修复pm_runtime错误处理 未检查 pm_runtime_get_sync（） 的返回值，从而允许驱动程序访问可能无法恢复的硬件。设备使用计数也会无条件增加。使用 pm_runtime_resume_and_get（） 来传播错误并避免在失败时增加使用计数。在 preenable 中，在 set_8khz_samplerate（） 失败时添加 pm_runtime_put_autosuspend（），因为 postdisable 在 preenable 失败时不运行。（CVE-2026-43357）

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

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

  - lib/crypto：chacha：在permuted_state离开范围之前将其归零 由于 ChaCha 排列是可逆的，因此即使在完成排列之后，本地变量“permuted_state”也足以计算原始“状态”和密钥。虽然内核在将堆栈上的秘密归零方面非常不一致（并且一些著名的用户空间加密库根本不打扰，因为无论如何都不能保证它有效），但内核确实尝试将其作为最佳实践，尤其是在涉及 RNG 的情况下。因此，在“permuted_state”超出范围之前，将其明确归零。（CVE-2026-43336）

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

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

  - smb：服务器：修复 smb2_open（） 中的释放后使用 通过 rcu_dereference（fp->f_opinfo） 获得的 opinfo 指针在 rcu_read_unlock（） 之后取消引用，从而创建释放后使用窗口。
    (CVE-2026-43378)

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

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

  - netfilter：flowtable：严格检查最大操作数 IPv6 中 flowtable 硬件卸载操作的最大数量为： * 以太网破坏（4 个负载操作，每个以太网地址 2 个）
    * SNAT（4 个负载操作）* DNAT（4 个负载操作）* QinQ 的双重 VLAN（4 个 vlan 操作，2 个用于弹出 vlan，2 个用于推送）。* 重定向（1 个动作）即为 17 个，而最大值为 16 个。但act_ct也支持隧道操作。请注意，负载操作在 32 位字级别运行，因此识别编码 IPv6 地址需要 4 个负载操作。更新 flow_action_entry_next（） 调用以检查支持的操作的最大数量。同时，将每个流的最大操作数从 16 增加到 24，以便这适用于 IPv6 设置。（CVE-2026-43329）

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

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

  - ALSA：usb-audio：检查解析 Scarlett2 混合器接口时的端点编号 传递畸形 USB 描述符时，USB-audio 驱动程序中的 Scarlett2 混音器 quirk 可能发生空取消引用，因为它假设 scarlett2_find_fc_interface（） 中的解析接口中存在端点，正如 fuzzer 所报告的那样。为避免空取消引用，只需添加 bNumEndpoints 的健全性检查并跳过无效接口。（CVE-2026-43436）

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

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

  - e1000/e1000e：修复 DMA 错误清理中的泄漏 如果在映射 TX 缓冲区时遇到错误，驱动程序应取消映射已为该 skb 映射的所有缓冲区。由于计数在成功映射后会递增，因此当达到dma_error时，计数将始终匹配所需的正确取消映射数量。在 dma_error 的 while 循环之前减少计数造成差一错误。如果在映射失败之前有任何映射成功，则会泄漏一个 DMA 映射。在这些提交中，错误的 while 条件导致了 dma_error中的无限循环： 提交 03b1320dfcee（e1000e：删除对 e1000e 驱动程序中的skb_dma_map的使用） 提交 602c0554d7b0（e1000：删除对 e1000 驱动程序中的skb_dma_map的使用） 提交 c1fa347f20f1（e1000/e1000e/igb/igbvf/ixgb/ixgbe：修复未登录测试 *_tx_map（）） 修复了无限循环， 但引入了差一错误。igbvf 驱动程序中可能仍然存在此问题，但我未在此修补程序中解决它。（CVE-2026-43445）

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

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

  - 已修复 Linux 内核中的下列漏洞：mshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER When registering VTL0 memory via MSHV_ADD_VTL0_MEMORY, the kernel computes pgmap->vmemmap_shift as the number of trailing zeros in the OR of start_pfn and last_pfn, intending to use the largest compound page order both endpoints are aligned to. However, this value is not clamped to MAX_FOLIO_ORDER, so a sufficiently aligned range (e.g. physical range [0x800000000000, 0x800080000000), corresponding to start_pfn=0x800000000 with 35 trailing zeros) can produce a shift larger than what memremap_pages() accepts, triggering a WARN and returning -EINVAL: WARNING: ... memremap_pages+0x512/0x650 requested folio size unsupported The MAX_FOLIO_ORDER check was added by commit 646b67d57589 (mm/memremap:
    reject unreasonable folio/compound page sizes in memremap_pages()). Fix this by clamping vmemmap_shift to MAX_FOLIO_ORDER so we always request the largest order the kernel supports, in those cases, rather than an out-of-range value. Also fix the error path to propagate the actual error code from devm_memremap_pages() instead of hard-coding -EFAULT, which was masking the real -EINVAL return. (CVE-2026-43348)

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

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

  - batman-adv：避免 double-rtnl_lock 在已经持有 RTNL 锁时调用 ELP 指标工作线程 batadv_v_elp_get_throughput（）。通过 batadv_v_elp_iface_disable（） 中的 cancel_delayed_work_sync（） 取消工作队列项目时，这可能会出现问题。在这种情况下，rtnl_lock（） 将导致死锁。为避免此情况，此函数中使用了 rtnl_trylock（） 来在已持有 RTNL 锁的情况下跳过 ethtool 信息的检索。但对于 cfg80211 接口，调用了 batadv_get_real_netdev（），后者也使用 rtnl_lock（）。还必须使用 __ethtool_get_link_ksettings（） 的方法代替，并且必须调用无锁版本 __batadv_get_real_netdev（）。（CVE-2026-43382）

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

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

  - fs：调用 vfs_fileattr_get 之前先flags_valid syzbot 在 [1] 中报告一个 uninit-value 缺陷。类似于在调用 vfs_fileattr_get（） 之前初始化内核内部file_kattr结构的 *get 上下文，我们在使用 fa 时应使用相同的机制。[1] 缺陷： KMSAN：fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c：517 中的 uninit-value fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c：517 vfs_fileattr_get fs/file_attr.c：94 [内联] __do_sys_file_getattr fs/file_attr.c：416 [内联] 创建的本地变量 fa.i： __do_sys_file_getattr fs/file_attr.c：380 [内联]
    __se_sys_file_getattr+0x8c/0xbd0 fs/file_attr.c：372 （CVE-2026-43474）

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

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

  - nvme-pci：修复 nvme_poll_irqdisable（） 中的争用缺陷在以下情况中，可通过 （2） 在 （1） 和 （3） 之间禁用 pdev。这会设置 pdev->msix_enabled = 0。然后，pci_irq_vector（） 将对 （1） 返回 MSI-X IRQ（>15），而对 （2） 返回 INTx IRQ（<=15）。这样会造成 IRQ 警告，方法是尝试启用之前从未禁用过的 INTx IRQ。要解决此问题，请将 IRQ 编号保存到本地变量中并确保 disable_irq（） 和 enable_irq（） 对同一个 IRQ 编号起作用。即使 pci_free_irq_vectors（） 同时释放 IRQ，过时 IRQ 编号上的 disable_irq（） 和 enable_irq（） 仍然有效且安全，并且深度核算会保持平衡。任务 1：nvme_poll_irqdisable（） disable_irq（pci_irq_vector（pdev， nvmeq->cq_vector）） ...（1） enable_irq（pci_irq_vector（pdev， nvmeq->cq_vector）） ...（3） 任务 2：
    nvme_reset_work（） nvme_dev_disable（） pdev->msix_enable = 0;...（2） 崩溃日志：------------[ 切入此处]------------ IRQ 10 的启用不平衡 警告：kernel/irq/manage.c：753 at __enable_irq+0x102/0x190 kernel/irq/manage.c：753， CPU#1： kworker/1：0H/26 模块链接： CPU：1 UID：0 PID：26 通信：
    kworker/1：0H 未受感染 6.19.0-dirty #9 PREEMPT（自愿） 硬件名称：QEMU Standard PC （i440FX + PIIX， 1996），BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 2014 年 4 月 1 日 工作队列：kblockd blk_mq_timeout_work RIP：0010：__enable_irq+0x107/0x190 kernel/irq/manage.c：753 代码：ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP： 0018：ffffc900001bf550 EFLAGS：
    00010046 RAX：0000000000000007 RBX：00000000000000000 RCX：ffffffffb20c0e90 RDX：00000000000000000 RSI：
    000000000000000a RDI： ffffffffb74b88f0 RBP： ffffc900001bf560 ： ffff88800197cf00 R09： 0000000000000001R10： 0000000000000003R11： 0000000000000003： ffff8880012a6000 R12R13： 1ffff92000037eaeR14：R08
    000000000000000a R15：0000000000000293 FS：0000000000000000（0000） GS：ffff8880b49f7000（0000） knlGS：0000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：0000555da4a25fa8 CR3：
    00000000208e8000 CR4：000000000000006f0 调用跟踪： <TASK> enable_irq+0x121/0x1e0 kernel/irq/manage.c：797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c：1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c：1744 blk_mq_rq_timed_out block/blk-mq.c：1653 [内联] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c：1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c：292
    __sbitmap_for_each_set include/linux/sbitmap.h：269 [内联] sbitmap_for_each_set include/linux/sbitmap.h：290 [内联] bt_for_each block/blk-mq-tag.c：324 [内联] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c：536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c：1763 process_one_work+0x956/0x1aa0 kernel/workqueue.c：3257 process_scheduled_works kernel/workqueue.c：3340 [内联] worker_thread+0x65c/0xe60 kernel/workqueue.c：3421 kthread+0x41a/0x930 kernel/kthread.c：463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：246 </TASK> irq 事件戳：74478 hardirqs 上次启用时间 （74477）：
    [<ffffffffb5720a9c>] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h：159 [内联] hardirqs 上次启用时间为 （74477）： [<ffffffffb5720a9c>] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c：202 hardirqs 上次禁用时间为 （74478）： [<ffffffffb57207b5>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h：108 [内联] hardirqs 上次禁用时间为 （74478）： [<ffffffffb57207b5>]
    _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c：162 softirqs 上次启用时间为 （74304）：
    [<ffffffffb1e9466c>] __do_softirq kernel/softirq.c：656 [内联] softirqs 上次启用时间为 （74304）：
    [<ffffffffb1e9466c>] invoke_softirq kernel/softirq.c：496 [内联] softirqs 上次启用时间为 （74304）：
    [<ffffffffb1e9466c>] __irq_exit_rcu+0xdc/0x120 ---truncated--- （CVE-2026-43448）

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

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

  - net/mlx5e：RX，修复 Striding RQ XDP multi-buf frag 计数 当程序调用 bpf_xdp_pull_data（） 或 bpf_xdp_adjust_tail（） 时，XDP multi-buf 程序可修改 XDP 缓冲区的布局。fixes 标签中引用的提交修正了 mlx5 驱动程序中 XDP 缓冲区布局在程序执行期间不会更改的假设。然而，此补丁引入了另一个问题：驱动程序端仍需要统计丢弃的片段，以避免页面片段引用计数问题。
    该问题是由 drivers/net/xdp.py selftest发现的，更具体地说是test_xdp_native_tx_mb：
    - mlx5 驱动程序分配一个page_pool页，并使用 frag 计数器 64 （pp_ref_count=64） 和内部 frag 计数器 0 对其进行初始化。- 测试发送一个没有负载的数据包。- 在 RX （mlx5e_skb_from_cqe_mpwrq_nonlinear（）） 上，mlx5 使用从第一个片段（即上述页面）开始的数据包数据配置 XDP 缓冲区。- XDP 程序运行并调用 bpf_xdp_pull_data（），将标头移动到 XDP 缓冲区的线性部分。由于数据包不包含更多数据，程序会丢弃尾部碎片，因为它不再包含任何负载 （pp_ref_count=63）。- mlx5 设备跳过对此片段的计数。内部碎片计数器仍为 0。- mlx5 释放页面的所有 64 个片段，但页面pp_ref_count为 63 => 负引用计数错误。测试期间导致的splat：警告：CPU：0 PID：188225 at ./include/net/page_pool/helpers.h：297 mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] 链接的模块：[...]CPU：0 UID：0 PID：
    188225 通信：ip 未受感染 6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_44 #1 无 硬件名称：QEMU 标准 PC （Q35 + ICH9,2009），BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 2014 年 4 月 1 日 RIP：
    0010：mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] [...]调用跟踪： <TASK> mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core] mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core] mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core] mlx5e_close_rq+0x78/0xa0 [mlx5_core] mlx5e_close_queues+0x46/0x2a0 [mlx5_core] mlx5e_close_channel+0x24/0x90 [mlx5_core] mlx5e_close_channels+0x5d/0xf0 [mlx5_core] mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core] mlx5e_change_mtu+0x11d/0x490 [mlx5_core] mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core] netif_set_mtu_ext+0xfc/0x240 do_setlink.isra.0+0x226/0x1100 rtnl_newlink+0x7a9/0xba0 rtnetlink_rcv_msg+0x220/0x3c0 netlink_rcv_skb+0x4b/0xf0 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x240 ___sys_sendmsg+0x7c/0xb0 [...] __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xc70 此问题也适用于在驱动程序中的不同代码路径中处理的 XDP_PASS。此修补程序通过对所有相关 XDP 操作（XDP_TX、XDP_REDIRECT 和 XDP_PASS）的所有原始 XDP 缓冲区片段执行页面碎片计数来修复此问题。
    这基本上是恢复到在 fixes 标签中提交之前的原始计数。由于 frag_page 仍然指向原始的尾部，因此需要以不同的方式计算 xdp_update_skb_frags_info（） 的nr_frags参数以反映新的nr_frags。（CVE-2026-43465）

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

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

  - media：chips-media：wave5：修复 PM 运行时使用计数下溢 将删除路径中的 pm_runtime_put_sync（） 替换为 pm_runtime_dont_use_autosuspend（），以便与探测中的 pm_runtime_use_autosuspend（） 正确配对。这可让 pm_runtime_disable（） 正确处理引用计数清除，而不管当前的暂停状态如何。驱动程序会在删除中无条件调用 pm_runtime_put_sync（），但设备可能已经因在探测中配置了自动暂停而暂停。当 autosuspend 已暂停设备时，使用计数为 0，pm_runtime_put_sync（） 会将其递减为 -1。这会在卸载模块时造成以下警告：------------[ cut here ]------------ WARNING： CPU： 1 PID： 963 at kernel/kthread.c：1430 kthread_destroy_worker+0x84/0x98 ...vdec 30210000.video-codec：运行时 PM 使用计数下溢！（CVE-2026-43301）

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

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

  - USB：dummy-hcd：修复锁定/同步错误 syzbot 测试能够在 drivers/usb/gadgets/udc/core.c 中的 usb_gadget_udc_reset（） 例程中引发寻址异常和崩溃，这是因为使用第二个（驱动程序）参数 NULL 调用所导致。错误调用程序是 dummy_hcd.c 中的 set_link_state（），出现该问题的原因是 USB 重置和驱动程序取消绑定之间的争用。这种种族是不可能的;提交 7dbd8f4cabd9（USB：dummy-hcd：修复错误的同步变更）以及一些后续提交，都是专门为防止此类问题而编写的。事实证明，代码中（至少）仍然存在两个错误。另一个修补程序将解决第二个错误;这个与第一个有关。产生造成 syzbot 崩溃的错误是因为 stop_activity（） 例程有时会丢弃然后重新获取 dum->lock 自旋锁。处理仿真 USB 重置时，在 dum->ints_enabled 测试之后和 dum->callback_usage 递增之前，set_link_state（） 中会调用 stop_activity（）。这允许另一个线程（执行驱动程序取消绑定）潜入并获取旋转锁，然后清除 dum->ints_enabled 和 dum->driver。通常，其他线程必须等待 dum->callback_usage 降为 0 才能清除 dum->driver，但在这种情况下不必等待，因为 dum->callback_usage 尚未递增。修复方法是递增 dum->callback_usage _before_ 调用 stop_activity（），而不是 after。然后执行取消绑定的线程将不会清理 dum->driver，直到对 usb_gadget_udc_reset（） 的调用安全返回，且 dum->callback_usage 再次递减之后。（CVE-2026-43327）

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

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

  - dm：删除假超时以避免泄漏请求 自提交 15f73f5b3e59（blk-mq：将故障注入移出 blk_mq_complete_request）后，驱动程序负责在适当的代码路径和机会调用 blk_should_fake_timeout（）。然而，dm 驱动程序并未实现自己的超时处理程序，而是依赖于其从属设备的超时处理。如果将 io-timeout-fail 错误注入 dm 设备，请求将会泄露且永远不会完成，从而造成任务无限期挂起。
    重现： 1. 准备具有 iSCSI 从设备 2.将 io-timeout-fail 注入 dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3.读取/写入 DM 4.iscsiadm -m node -u 结果：挂起如下所示的任务 [ 862.243768] INFO：任务 kworker/u514：2：151 阻塞超过 122 秒。[ 862.244133] 受感染：G E 6.19.0-rc1+ #51 [ 862.244337] echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。[ 862.244718] task：kworker/u514：2 state：D stack：0 pid：151 tgid：151 ppid：2 task_flags：0x4288060 flags：0x00080000 [ 862.245024] 工作队列：iscsi_ctrl_3：1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] 调用跟踪：[ 862.245587] <TASK>862.245814[ ]
    __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995]
    __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095]
    __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654]
    __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] 从 </TASK> dm 删除 blk_should_fake_timeout（） 检查，因为 dm 没有本机超时处理，不应尝试假超时。（CVE-2026-43314）

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

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

  - media：uvcvideo：start_streaming（） 失败时返回排队的缓冲区 如果流由于 uvc_pm_get（） 错误而无法启动，则返回缓冲区。此错误可能是我在运行期间运行的警告的原因：;do yavta
    -c3 /dev/video0;在此工作负载下发生故障的 xHCI 控制器上完成。我没有幸运地再次复制此警告以确认。xhci_hcd 0000：09：00.0：HC 已终止;清理 USB 13-2：USB 断开连接，设备编号为 2 警告：CPU：2 PID：29386 at drivers/media/common/videobuf2/videobuf2-core.c：1803 vb2_start_streaming+0xac/0x120 （CVE-2026-43290）

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

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

  - kprobes：避免 ftrace 终止之后 rmmod/insmod 发生崩溃 命中 ftrace 因某些错误终止后，如果删除 kprobe 探测的模块，内核会崩溃。缺陷：无法处理地址的页面错误：fffffbfff805000d PGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0 错误：错误：0000 [#1] SMP KASAN PTI CPU：4 UID：0 PID：2012 通信：rmmod 受感染：G W OE 受感染：[W]=WARN，[O]=OOT_MODULE，[E]=UNSIGNED_MODULE RIP：0010：kprobes_module_callback+0x89/0x790 RSP：0018：ffff88812e157d30 EFLAGS：
    00010a02 RAX：1ffffffff805000d RBX：dffffc0000000000 RCX：ffffffff86a8de90 RDX：ffffed1025c2af9b RSI：
    0000000000000008 RDI： ffffffffc0280068 RBP： 00000000000000000 ： 0000000000000001 R09： ffffed1025c2af9a R10： ffff88812e157cd7 R11： 205d323130325420 R12： 0000000000000002 R13： ffffffffc0290488R14：R08
    0000000000000002 R15：ffffffffc0280040 FS：00007fbc450dd740（0000） GS：ffff888420331000（0000） knlGS：0000000000000000 CS：0010 DS：0000 ES：0000 CR0：0000000080050033 CR2：fffffbfff805000d CR3：
    000000010f624000 CR4： 000000000000006f0 调用追踪： <TASK> notifier_call_chain+0xc6/0x280 blocking_notifier_call_chain+0x60/0x90 __do_sys_delete_module.constprop.0+0x32a/0x4e0 do_syscall_64+0x5d/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e 这是因为 ftrace 上的 kprobe 未正确处理 ftrace_kill（） 设置的 kprobe_ftrace_disabled 标志。要避免此错误，请检查 __disarm_kprobe_ftrace（） 中的kprobe_ftrace_disabled并跳过所有与 ftrace 有关的操作。
    (CVE-2026-43409)

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

ID	名称	严重性
313391	Linux Distros 未修补的漏洞：CVE-2026-43344	medium
313390	Linux Distros 未修补的漏洞：CVE-2026-43398	medium
313389	Linux Distros 未修补的漏洞：CVE-2026-43383	critical
313388	Linux Distros 未修补的漏洞：CVE-2026-43472	medium
313387	Linux Distros 未修补的漏洞：CVE-2026-43303	high
313386	Linux Distros 未修补的漏洞：CVE-2026-43316	medium
313385	Linux Distros 未修补的漏洞：CVE-2026-43370	high
313384	Linux Distros 未修补的漏洞：CVE-2026-43299	medium
313383	Linux Distros 未修补的漏洞：CVE-2026-43405	high
313382	Linux Distros 未修补的漏洞：CVE-2026-43353	high
313381	Linux Distros 未修补的漏洞：CVE-2026-43450	high
313380	Linux Distros 未修补的漏洞：CVE-2026-43334	high
313379	Linux Distros 未修补的漏洞：CVE-2026-43439	medium
313378	Linux Distros 未修补的漏洞：CVE-2026-43437	high
313377	Linux Distros 未修补的漏洞：CVE-2026-43305	medium
313376	Linux Distros 未修补的漏洞：CVE-2026-43475	medium
313375	Linux Distros 未修补的漏洞：CVE-2026-43429	medium
313374	Linux Distros 未修补的漏洞：CVE-2026-43287	medium
313373	Linux Distros 未修补的漏洞：CVE-2026-43295	medium
313372	Linux Distros 未修补的漏洞：CVE-2026-43458	high
313371	Linux Distros 未修补的漏洞：CVE-2026-43338	medium
313370	Linux Distros 未修补的漏洞：CVE-2026-43326	medium
313369	Linux Distros 未修补的漏洞：CVE-2026-43302	medium
313368	Linux Distros 未修补的漏洞：CVE-2026-43350	high
313367	Linux Distros 未修补的漏洞：CVE-2026-43463	medium
313366	Linux Distros 未修补的漏洞：CVE-2026-43406	critical
313365	Linux Distros 未修补的漏洞：CVE-2026-41650	medium
313364	Linux Distros 未修补的漏洞：CVE-2026-43426	high
313363	Linux Distros 未修补的漏洞：CVE-2026-43318	medium
313362	Linux Distros 未修补的漏洞：CVE-2026-43419	medium
313361	Linux Distros 未修补的漏洞：CVE-2026-43459	high
313360	Linux Distros 未修补的漏洞：CVE-2026-43471	medium
313359	Linux Distros 未修补的漏洞：CVE-2026-43296	high
313358	Linux Distros 未修补的漏洞：CVE-2026-43466	high
313357	Linux Distros 未修补的漏洞：CVE-2026-43357	medium
313356	Linux Distros 未修补的漏洞：CVE-2026-43336	high
313355	Linux Distros 未修补的漏洞：CVE-2026-43378	high
313354	Linux Distros 未修补的漏洞：CVE-2026-43329	high
313353	Linux Distros 未修补的漏洞：CVE-2026-43436	medium
313352	Linux Distros 未修补的漏洞：CVE-2026-43445	medium
313351	Linux Distros 未修补的漏洞：CVE-2026-43348	medium
313350	Linux Distros 未修补的漏洞：CVE-2026-43382	medium
313349	Linux Distros 未修补的漏洞：CVE-2026-43474	medium
313348	Linux Distros 未修补的漏洞：CVE-2026-43448	medium
313347	Linux Distros 未修补的漏洞：CVE-2026-43465	critical
313346	Linux Distros 未修补的漏洞：CVE-2026-43301	medium
313345	Linux Distros 未修补的漏洞：CVE-2026-43327	medium
313344	Linux Distros 未修补的漏洞：CVE-2026-43314	medium
313343	Linux Distros 未修补的漏洞：CVE-2026-43290	high
313342	Linux Distros 未修补的漏洞：CVE-2026-43409	medium

检测

Nessus 的 Misc. 系列

medium

medium

critical

medium

high

medium

high

medium

high

high

high

high

medium

high

medium

medium

medium

medium

medium

high

medium

medium

medium

high

medium

critical

medium

high

medium

medium

high

medium

high

high

medium

high

high

high

medium

medium

medium

medium

medium

medium

critical

medium

medium

medium

high

medium