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

  - powerpc、perf：获取用户调用链前检查 current->mm 是否处于活动状态 可能已经释放 mm，从而导致内核错误。这添加了对 current->mm 的 NULL 检查，类似于提交 20afc60f892d（x86、perf：在获取用户调用链之前检查 current->mm 是否处于活动状态）。我在运行分析 BPF 程序时遇到此错误（从 bcc-tools profile.py）：[26215.051935] 内核尝试读取用户页面 （588） - 尝试利用？（uid：0） [26215.051950] 缺陷：0x00000588 处读取时发生内核空指针取消引用 [26215.051952] 错误指令地址：0xc00000000020fac0 [26215.051957] 错误：错误区域的内核访问，sig：11 [#1] [...][26215.052049] 调用跟踪：
    [26215.052050] [c000000061da6d30] [c00000000020fc10] perf_callchain_user_64+0x2d0/0x490（不可靠） [26215.052054] [c000000061da6dc0] [c00000000020f92c] perf_callchain_user+0x1c/0x30 [26215.052057] [c000000061da6de0] [c0000000005ab2a0] get_perf_callchain+0x100/0x360 [26215.052063] [c000000061da6e70] [c000000000573bc8] bpf_get_stackid+0x88/0xf0 [26215.052067] [c000000061da6ea0] [c008000000042258] bpf_prog_16d4ab9ab662f669_do_perf_event+0xf8/0x274 [...]此外，将存储顶级堆栈条目的移至通用perf_callchain_user，以确保即使 current->mm 为 NULL，也始终捕获 top-evel 条目。[Maddy：已修复消息以避免 checkpatch 格式样式错误]（CVE-2026-43416）

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

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

  - usb：class：cdc-wdm：修复读取代码路径中的重新排序问题 引用缺陷报告：由于编译器优化或 CPU 无序执行，desc->长度更新可在 memmove 之前重新排序。
    如果发生这种情况，wdm_read（） 可看到新的长度并调用未初始化内存上的 copy_to_user（）。这也违反了 LKMM 数据争用规则 [1]。使用WRITE_ONCE和内存屏障修复此问题。（CVE-2026-43427）

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

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

  - libceph：修复 ceph_handle_auth_reply（） 中潜在的越界访问 此修补程序修复了 ceph_handle_auth_reply（） 中可通过 CEPH_MSG_AUTH_REPLY 类型消息触发的越界访问。在 ceph_handle_auth_reply（） 中，此类消息的 payload_len 字段的值存储在 int 类型的变量中。大于 INT_MAX 的值会导致整数溢出并被解释为负值。这会导致递减指针地址此值并随后访问它，因为 ceph_decode_need（） 仅检查内存访问是否超过分配的结束地址。
    此修补程序将 payload_len 的数据类型更改为 u32 来修复此问题。此外，result_msg_len 的数据类型更改为 u32，因为它也是持有非负长度的变量。此外，还引入了额外的健全性检查层，确保从消息读取后，payload_len和result_msg_len不会大于整个段长度。缺陷：KASAN：ceph_handle_auth_reply+0x642/0x7a0 中的 slab-out-of-bound [libceph] 任务 kworker/20:1/262 在地址 ffff88811404df14 读取大小为 4 CPU：20 UID：0 PID：262 Comm：kworker/20:1 未受 6.19.2 #5 感染 PREEMPT（自愿） 硬件名称：QEMU Standard PC （i440FX + PIIX， 1996），BIOS 1.16.3-debian-1.16.3-2 04/01/2014 工作队列：
    ceph-msgr ceph_con_workfn [libceph] 调用跟踪： <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x620 ？
    __pfx__raw_spin_lock_irqsave+0x10/0x10 ？kasan_complete_mode_report_info+0x72/0x210 kasan_report+0xe7/0x130 ？ceph_handle_auth_reply+0x642/0x7a0 [libceph] ？ceph_handle_auth_reply+0x642/0x7a0 [libceph] __asan_report_load_n_noabort+0xf/0x20 ceph_handle_auth_reply+0x642/0x7a0 [libceph] mon_dispatch+0x973/0x23d0 [libceph] ？apparmor_socket_recvmsg+0x6b/0xa0 ？__pfx_mon_dispatch+0x10/0x10 [libceph] ？
    __kasan_check_write+0x14/0x30i ？mutex_unlock+0x7f/0xd0 ？__pfx_mutex_unlock+0x10/0x10 ？
    __pfx_do_recvmsg+0x10/0x10 [libceph] ceph_con_process_message+0x1f1/0x650 [libceph] process_message+0x1e/0x450 [libceph] ceph_con_v2_try_read+0x2e48/0x6c80 [libceph] ？
    __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph] ？save_fpregs_to_fpstate+0xb0/0x230 ？raw_spin_rq_unlock+0x17/0xa0 ？finish_task_switch.isra.0+0x13b/0x760 ？__switch_to+0x385/0xda0 ？
    __kasan_check_write+0x14/0x30 ？mutex_lock+0x8d/0xe0 ？__pfx_mutex_lock+0x10/0x10 ceph_con_workfn+0x248/0x10c0 [libceph] process_one_work+0x629/0xf80 ？__kasan_check_write+0x14/0x30 worker_thread+0x87f/0x1570 ？__pfx__raw_spin_lock_irqsave+0x10/0x10 ？__pfx_try_to_wake_up+0x10/0x10 ？kasan_print_address_stack_frame+0x1f7/0x280 ？__pfx_worker_thread+0x10/0x10 kthread+0x396/0x830 ？
    __pfx__raw_spin_lock_irq+0x10/0x10 ？__pfx_kthread+0x10/0x10 ？__kasan_check_write+0x14/0x30 ？recalc_sigpending+0x180/0x210 ？__pfx_kthread+0x10/0x10 ret_from_fork+0x3f7/0x610 ？
    __pfx_ret_from_fork+0x10/0x10 ？__switch_to+0x385/0xda0 ？__pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> [ idryomov：将 if 语句替换为用于 payload_len 和 result_msg_len 的 ceph_decode_need（） ] （CVE-2026-43407）

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

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

  - ipv6：防止 addrconf_permanent_addr（） 中可能的 UaF 上述帮助程序尝试警告用户异常情况，但消息传递太晚，导致在可能被删除后访问 ipv6。重新排序语句以避免可能的 UAF;同时，请将警告放在 idev->lock 之外，因为它不需要任何保护。（CVE-2026-43339）

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

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

  - 已修复 Linux 内核中的下列漏洞：f2fs: fix to avoid uninit-value access in f2fs_sanity_check_node_footer syzbot reported a f2fs bug as below: BUG: KMSAN: uninit-value in f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520 f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520 f2fs_finish_read_bio+0xe1e/0x1d60 fs/f2fs/data.c:177 f2fs_read_end_io+0x6ab/0x2220 fs/f2fs/data.c:-1 bio_endio+0x1006/0x1160 block/bio.c:1792 submit_bio_noacct+0x533/0x2960 block/blk-core.c:891 submit_bio+0x57a/0x620 block/blk-core.c:926 blk_crypto_submit_bio include/linux/blk-crypto.h:203 [inline] f2fs_submit_read_bio+0x12c/0x360 fs/f2fs/data.c:557 f2fs_submit_page_bio+0xee2/0x1450 fs/f2fs/data.c:775 read_node_folio+0x384/0x4b0 fs/f2fs/node.c:1481
    __get_node_folio+0x5db/0x15d0 fs/f2fs/node.c:1576 f2fs_get_inode_folio+0x40/0x50 fs/f2fs/node.c:1623 do_read_inode fs/f2fs/inode.c:425 [inline] f2fs_iget+0x1209/0x9380 fs/f2fs/inode.c:596 f2fs_fill_super+0x8f5a/0xb2e0 fs/f2fs/super.c:5184 get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694 get_tree_bdev+0x38/0x50 fs/super.c:1717 f2fs_get_tree+0x35/0x40 fs/f2fs/super.c:5436 vfs_get_tree+0xb3/0x5d0 fs/super.c:1754 fc_mount fs/namespace.c:1193 [inline] do_new_mount_fc fs/namespace.c:3763 [inline] do_new_mount+0x885/0x1dd0 fs/namespace.c:3839 path_mount+0x7a2/0x20b0 fs/namespace.c:4159 do_mount fs/namespace.c:4172 [inline] __do_sys_mount fs/namespace.c:4361 [inline]
    __se_sys_mount+0x704/0x7f0 fs/namespace.c:4338 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4338 x64_sys_call+0x39f0/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x134/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is: in f2fs_finish_read_bio(), we may access uninit data in folio if we failed to read the data from device into folio, let's add a check condition to avoid such issue. (CVE-2026-43349)

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

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

  - staging：rtl8723bs：正确验证 rtw_get_ie_ex（） 中的数据 就像在提交 154828bf9559 中一样（staging：rtl8723bs：修复 rtw_get_ie（） 解析器中的越界读取），我们不信任帧中的数据，因此我们应在对其执行操作前更好地检查长度 （CVE-2026-43387）

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

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

  - 媒体：芯原：解码 H.264 和 HEVC 时避免 G2 总线错误 对于 i.MX8MQ 平台，存在硬件限制：g1 VPU 和 g2 VPU 无法同时解码;否则，将导致总线以下错误并产生损坏的图片，甚至可能导致系统挂起。[ 110.527986] hantro-vpu 38310000.video-codec：帧解码超时。[ 110.583517] hantro-vpu 38310000.video-codec：检测到总线错误。因此，需要确保 g1 和 g2 交替运行。这可成功解码 H.264 和 HEVC 的多实例。为了实现这一点，g1 和 g2 共享相同的v4l2_m2m_dev，然后v4l2_m2m_dev可以处理调度。（CVE-2026-43310）

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

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

  - x86/kexec：load_segments（） 后禁用 KCOV 检测 load_segments（） 函数更改段寄存器，使 GS 基（KCOV 用于 per-cpu 数据）失效。启用 CONFIG_KCOV 时，任何后续的检测 C 代码调用（如 native_gdt_invalidate（））都会开始在死循环中造成内核崩溃。要重现该问题，只需在 KCOV 检测的内核上执行 kexec 即可：$ kexec
    -l /boot/otherKernel $ kexec -e 此问题的实际环境是在 syzkaller 中启用崩溃转储集合。为此，该工具会在模糊测试前加载错误内核，然后在错误之后调用 makedumpfile。此工作流需要同时启用 CONFIG_KEXEC 和 CONFIG_KCOV。此外，不希望直接向 KCOV 快速路径 （__sanitizer_cov_trace_pc（）） 添加安全，因为这会造成额外的性能开销。禁用各个函数的检测过于脆弱，因此请禁用整个 machine_kexec_64.c 和 physaddr.c 的 KCOV 检测。如果覆盖引导的模糊测试将来需要这些组件，则应考虑其他方法。
    该问题与 32 位内核无关，因为 32 位内核不支持 CONFIG_KCOV。[ bp： 为提高可读性，请留出注释间距。 ]（CVE-2026-43331）

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

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 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - libceph：防止 process_message_header（） 中潜在的越界读取 如果消息帧（恶意）损坏的方式导致控制段长度最终小于消息标头的大小，或者将不同的帧改造成看起来像消息帧，则 process_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 依赖供应商报告的程序包是否存在进行判断。

ID	名称	严重性
313399	Linux Distros 未修补的漏洞：CVE-2026-43416	medium
313398	Linux Distros 未修补的漏洞：CVE-2026-43427	high
313397	Linux Distros 未修补的漏洞：CVE-2026-43407	critical
313396	Linux Distros 未修补的漏洞：CVE-2026-43339	high
313395	Linux Distros 未修补的漏洞：CVE-2026-43349	medium
313394	Linux Distros 未修补的漏洞：CVE-2026-43387	medium
313393	Linux Distros 未修补的漏洞：CVE-2026-43310	medium
313392	Linux Distros 未修补的漏洞：CVE-2026-43331	medium
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

检测

Nessus 的 Misc. 系列

medium

high

critical

high

medium

medium

medium

medium

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