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 依赖供应商报告的程序包是否存在进行判断。

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

  - scsi：qla2xxx：完全修复 fcport 双重释放。在 qla24xx_els_dcmd_iocb（） sp->free 设为 qla2x00_els_dcmd_sp_free（） 时。发生错误时，kref_put（） 释放第一个和最后一个引用时，qla2x00_sp_release（） 将调用此函数。qla2x00_els_dcmd_sp_free（） 通过调用 qla2x00_free_fcport（） 释放 fcport。在 kref_put（） 之后再做一次是个坏主意。（CVE-2026-43414）

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

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

  - USB： core：限制无法终止的同步超时的长度 usbcore 中的 usb_control_msg（）、usb_bulk_msg（） 和 usb_interrupt_msg（） API 允许无限的超时持续时间。由于他们使用不间断的等待，这留下了无限期长时间挂起任务的可能性，除非拔下目标设备，否则无法终止它。若要防止此类问题的发生，请对这些不可终止的超时的时长设定最大限制。这里选择的限制有点随意，是 60 秒。在许多系统（尽管不是全部）上，此设置足够短，可避免触发内核的挂起任务检测器。
    此外，通过将其视为 0（即使用允许的最大超时）等同，消除负超时值的歧义。（CVE-2026-43428）

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

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

  - drm/amd/display：修复 dcn401_init_hw（） 中的空指针取消引用 dcn401_init_hw（） 在输入更新路径时假设 update_bw_bounding_box（） 有效。然而，现有条件：
    （（！fams2_enable &; update_bw_bounding_box） || freq_changed） 不能保证这一点，因为 freq_changed 分支可以独立于回调指针评估为 true。这可在 update_bw_bounding_box（） 为 NULL 时导致调用。通过将更新条件与指针检查分开，并确保在使用前验证回调、dc->clk_mgr和bw_params来修复此问题。修复了以下问题：
    ../dc/hwss/dcn401/dcn401_hwseq.c：367 dcn401_init_hw（） 错误：我们之前假设“dc->res_pool->funcs->update_bw_bounding_box”可能为空（请参阅第 362 行）（从提交 86117c5ab42f21562fedb0a64bffea3ee5fcd477 中精选出的内容）（CVE-2026-43337）

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

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

  - nouveau/dpcd：如果设备处于休眠状态，则返回 aux xfer 的 EBUSY 如果已暂停运行时，而用户空间想要使用 /dev/drm_dp_*，则只需在 GSP 代码中告知设备忙碌，而非崩溃。警告：CPU：2 PID：drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c：164 r535_gsp_msgq_wait+0x9a/0xb0 565741 [nouveau] CPU：2 UID：0 PID：565741 通信：fwupd 未受感染 6.18.10-200.fc43.x86_64 #1 PREEMPT（lazy） 硬件名称：LENOVO 20QTS0PQ00/20QTS0PQ00，BIOS N2OET65W （1.52） 08/05/2024 RIP：0010：r535_gsp_msgq_wait+0x9a/0xb0 [nouveau] 这是向后移植的简单补丁。我们可能应该设计一个适当的电源域解决方案来唤醒设备并在固件更新发生时保持它们保持唤醒。（CVE-2026-43381）

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

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

  - tipc：修复 tipc_sk_filter_connect（） 中的除以零问题 用户可通过 setsockopt（TIPC_CONN_TIMEOUT） 将conn_timeout设置为任何值，包括小于 4 的值。当 TIPC_ERR_OVERLOAD 拒绝 SYN 且 tipc_sk_filter_connect（） 中的重试路径执行时：延迟 %= （tsk->conn_timeout / 4）;如果 conn_timeout 在 [0， 3] 范围内，整数除法会产生 0，而模数运算会触发除以零异常，从而造成内核 oops/错误。通过在 tipc_sk_filter_connect（） 的使用点将conn_timeout限制为最小值 4 来修复此问题。错误：除法错误：0000 [#1] SMP KASAN NOPTI CPU：0 UID：0 PID：119 通信：poc-F144 未受感染 7.0.0-rc2+ RIP：0010：tipc_sk_filter_rcv （net/tipc/socket.c：2236 net/tipc/socket.c：2362） 调用跟踪：tipc_sk_backlog_rcv （include/linux/instrumented.h：82 include/linux/atomic/atomic-instrumented.h：32 include/net/sock.h：2357 net/tipc/socket.c：2406）
    __release_sock （include/net/sock.h：1185 net/core/sock.c：3213） release_sock （net/core/sock.c：3797） tipc_connect （net/tipc/socket.c：2570） __sys_connect （include/linux/file.h：62 include/linux/file.h：83 net/socket.c：2098） （CVE-2026-43411）

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

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

  - usb：gadget：f_subset：修复 geth_free geth_alloc（） 中不平衡的 refcnt 增加引用计数，但 geth_free（） 无法减少引用计数。这样会阻止断开函数链接后通过 configfs 配置属性。减少 geth_free（） 中的引用计数以确保正确清理。
    (CVE-2026-43343)

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

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

  - usb：yurex：修复探测中的争用 必须先将描述符的 bbu 成员设置为代表未初始化值的值，然后才能提交其完成处理程序集 bbu 的 URB。否则存在一个窗口期，在此期间探测可覆盖已检索的数据。（CVE-2026-43430）

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

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

  - spi：spidev：修复 spi_lock 和 buf_lock 之间的锁定反转 spidev 驱动程序之前使用两个互斥体：spi_lock 和 buf_lock，但根据代码路径以不同的顺序获取它们：
    write（）/read（）：buf_lock -> spi_lock ioctl（）：spi_lock -> buf_lock 此 AB-BA 锁定模式会触发 lockdep 警告，而且可造成真正的死锁：警告：检测到可能的循环锁定依赖关系 spidev_ioctl（） -> mutex_lock（&spidev->buf_lock） spidev_sync_write（） -> mutex_lock（&spidev->spi_lock） *** 死锁 *** 通过从同一 spidev 上的不同线程执行 write（） 和 SPI_IOC_WR_MAX_SPEED_HZ ioctl（） 调用的简单用户空间程序可重现此问题文件描述符。通过简化锁定模型并完全删除锁定反转修复此问题。spidev_sync（） 不再执行任何锁定，所有调用程序都使用spi_lock序列化访问。buf_lock已被删除，因为spi_lock完全覆盖了的功能，从而消除了锁定排序问题的可能性。此操作删除了锁定反转，并在不更改用户空间 ABI 或行为的情况下防止死锁。
    (CVE-2026-43319)

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

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

  - netfilter：nft_set_pipapo：修复 pipapo_drop（） 中的堆栈越界读取 pipapo_drop（） 在每次迭代时（包括最后一次迭代 i == m->field_count - 1） 时，将 rulemap[i + 1].n 作为to_offset参数传递给 pipapo_unmap（）。这会读取一个元素超过堆栈分配的规则映射数组的末尾（声明为 rulemap[NFT_PIPAPO_MAX_FIELDS]，NFT_PIPAPO_MAX_FIELDS == 16）。尽管 pipapo_unmap（） 在 is_last 为 true 时不使用to_offset值时提早返回，但在函数正文执行之前会在调用站点对参数进行评估，从而使此成为真正的越界堆栈读取，这一点经 KASAN 确认： 缺陷： KASAN：
    pipapo_drop+0x50c/0x57c 中的堆栈越界 [nf_tables] 地址 ffff8000810e71a4 处的读取大小为 4 此框架有 1 个对象：[32， 160）'rulemap' 有缺陷的地址位于偏移 164 -- 刚好超出 rulemap 数组结尾 4 字节处。在最后一次迭代中传递 0 而不是 rulemap[i + 1].n 以避免越界读取。（CVE-2026-43453）

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

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

  - most：core：修复早期注册失败时的泄漏 最近的提交修复了早期注册失败时的资源泄漏，但由于某些原因遗漏了第一个仍会泄漏与接口关联的资源的错误路径。还修复了第一个错误路径，以便在出错时始终释放接口。（CVE-2026-43317）

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

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

  - ext4：将 ext4_percpu_param_init（） 移动到 ext4_mb_init（） 之前 当在定义“DOUBLE_CHECK”宏的情况下运行“kvm-xfstests -c ext4/1k -C 1 generic/383”时，将触发以下错误：
    ================================================================== EXT4-fs 错误（设备 vdc）：
    ext4_validate_block_bitmap：423：comm mount：bg 0：错误的块位图校验和缺陷：无法处理地址的页面错误：ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops： Oops： 0000 [#1] SMP NOPTI CPU： 0 UID： 0 PID： 2386 comm： mount 受感染： G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT（none） RIP：
    0010：percpu_counter_add_batch+0x13/0xa0 调用跟踪： <TASK> ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640
    __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== 此问题可使用以下命令重现：mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota，项目 /dev/sda 挂载 /dev/sda /tmp/test 定义DOUBLE_CHECK后，mb_group_bb_bitmap_alloc（） 将读取并验证区块位图。如果验证失败，ext4_mark_group_bitmap_corrupted（） 将尝试更新 sbi->s_freeclusters_counter。
    但是，此percpu_counter此时尚未初始化，因此会导致上述错误。通过将 ext4_percpu_param_init（） 的执行移动到在 ext4_mb_init（） 之前进行修复，确保在使用之前初始化 per-CPU 计数器。（CVE-2026-43288）

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

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

  - soc/tegra： pmc： 修复不安全的 generic_handle_irq（） 调用 目前，当在 Tegra 平台上从系统暂停状态恢复时，会出现下列警告： 警告： CPU： 0 PID： 14459 at kernel/irq/irqdesc.c：666 调用跟踪： handle_irq_desc+0x20/0x58 （P） tegra186_pmc_wake_syscore_resume+0xe4/0x15c syscore_resume+0x3c/0xb8 suspend_devices_and_enter+0x510/0x540 pm_suspend+0x16c/0x1d8 发生警告的原因是从非中断呼叫 generic_handle_irq（）上下文 （被视为不安全）。通过将 generic_handle_irq（） 调用延迟到可在可安全调用的硬 IRQ 上下文中执行的 IRQ 工作来修复此警告generic_handle_irq。使用 PREEMPT_RT 内核时，常规 IRQ 工作（使用 init_irq_work 初始化）会被推迟为在可抢占上下文（而不是硬 IRQ 上下文）的按 CPU kthread 中运行。因此，请使用 IRQ_WORK_INIT_HARD 变体，以便通过 PREEMPT_RT 内核，在 hardirq 上下文中处理 IRQ 工作，而不是延迟至调用 generic_handle_irq（） 所需的线程。在非PREEMPT_RT内核中，init_irq_work（） 和 IRQ_WORK_INIT_HARD（） 都在 IRQ 上下文中执行，因此此更改对标准内核配置没有功能影响。
    [treding@nvidia.com：其他清理]（CVE-2026-43311）

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

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

  - iavf：修复重置提交期间的 PTP 释放后使用 提交 7c01dbfc8a1c5f（iavf：定期缓存 PHC 时间）引入工作线程来缓存 PHC 时间，但在重置或禁用期间无法停止。这会造成争用条件，其中“iavf_reset_task（）”或“iavf_disable_vf（）”会在工作线程仍在运行时释放适配器资源 （AQ）。如果工作线程在拆卸期间触发“iavf_queue_ptp_cmd（）”，它将访问已释放的内存/锁，从而导致崩溃。通过在拆卸适配器之前调用“iavf_ptp_release（）”来修复此问题。这可确保“ptp_clock_unregister（）”在销毁后备资源之前同步取消工作线程并清理 chardev。（CVE-2026-43447）

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

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

  - nvme-pci：修复 dev->online_queues 中的 slab-out-of-bound nvme_dbbuf_set以 nvme_init_queue 递增的计数。因此，有效索引为 0 到 dev->online_queues 1。此修补程序修复了循环情况，以确保索引保持在有效范围内。索引 0 被排除在外，因为它是管理队列。KASAN SPLAT：================================================================== 缺陷：KASAN：nvme_dbbuf_free drivers/nvme/host/pci.c：377 中的 slab-out-of-bound [inline] 缺陷：KASAN：在 nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c：404 中的 slab-out-of-bound 由任务 kworker/u8：5/74 在地址 ffff88800592a574 读取的大小为 2 CPU：0 UID：0 PID：74 Comm：kworker/u8：5 未受感染 6.19.0-dirty #10 PREEMPT（自愿） 硬件名称：QEMU Standard PC （i440FX + PIIX， 1996）， BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org04/01/2014 工作队列： nvme-reset-wq nvme_reset_work 调用跟踪： <TASK> __dump_stack lib/dump_stack.c：94 [内联] dump_stack_lvl+0xea/0x150 lib/dump_stack.c：120 print_address_description mm/kasan/report.c：378 [内联] print_report+0xce/0x5d0 mm/kasan/report.c：482 kasan_report+0xdc/0x110 mm/kasan/report.c：595
    __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c：379 nvme_dbbuf_free drivers/nvme/host/pci.c：377 [内联] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c：404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c：3252 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> 由任务 34 在 CPU 1 上的 4.241550s 分配：kasan_save_stack+0x2c/0x60 mm/kasan/common.c：57 kasan_save_track+0x1c/0x70 mm/kasan/common.c：78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c：570 poison_kmalloc_redzone mm/kasan/common.c：398 [内联] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c：415 kasan_kmalloc include/linux/kasan.h：263 [inline] __do_kmalloc_node mm/slub.c：5657 [内联]
    __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c：5663 kmalloc_array_node_noprof include/linux/slab.h：1075 [内联] nvme_pci_alloc_dev drivers/nvme/host/pci.c：3479 [内联] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c：3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c：324 pci_call_probe drivers/pci/pci-driver.c：392 [内联] __pci_device_probe drivers/pci/pci-driver.c：417 [内联] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c：451 call_driver_probe drivers/base/dd.c：583 [内联] really_probe+0x29b/0xb70 drivers/base/dd.c：661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c：803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c：833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c：1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c：129 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 有缺陷的地址属于位于 ffff88800592a000 的对象，该对象属于大小为 2048 的缓存 kmalloc-2k 有缺陷的地址位于分配的 1152 字节区域右侧 244 字节处 [ffff88800592a000， ffff88800592a480） 错误地址属于物理页面：page： refcount：0 mapcount：0 mapping：000000000000000 index：0x0 pfn：0x5928 head： order：3 mapcount：0 entire_mapcount：0 nr_pages_mapped：0 pincount：0 anon flags： 0xfffffc0000040（head|node=0|zone=1|lastcpupid=0x1fffff） page_type：f5（slab） raw：
    000fffffc0000040 ffff888001042000 000000000000000000 死00000000000001 raw： 0000000000000000000 0000000000080008 000000000f500000000000000000 头： 000fffffc0000040 ffff888001042000 000000 ---truncated--- （CVE-2026-43449）

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

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

  - wifi：iwlwifi： mvm：不受支持时不发送与 6E 相关的命令MCC_ALLOWED_AP_TYPE_CMD与 6E 支持有关。如果设备不支持 6E，请勿发送。显然，固件错误地宣传了对此命令的支持，即使在不支持 6E 的命令上 AX201 也是如此，然后固件崩溃。（CVE-2026-43325）

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

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

  - btrfs：不对 run_one_delayed_ref（） 中非预期的延迟 ref 类型执行 BUG（） 不需要 BUG（），我们只需返回错误并记录错误消息即可。（CVE-2026-43308）

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

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

  - bonding：修复 net/core/skbuff.c：2306！ 的 bond_setup_by_slave（） 内核缺陷中的类型混淆！哎呀：无效操作码：0000 [#1] SMP KASAN NOPTI RIP：0010：pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c：2306 RSP：
    0018：ffffc90004aff760 EFLAGS： 00010293 RAX： 0000000000000000 RBX： ffff88807e3c8780 RCX： ffffffff89593e0e RDX： ffff88807b7c4900 RSI： ffffffff89594747 RDI： ffff88807b7c4900 RBP： 0000000000000820 R08：
    0000000000000005 R09： 0000000000000000 R10： 000000000961a63e0 R11： 0000000000000000 R12： ffff88807e3c8780 R13： 00000000961a6560 R14： dffffc00000000000 R15： 00000000961a63e0 CS： 0010 DS： 0000 ES： 0000 CR0：
    0000000080050033 CR2：00007fe1a0ed8df0 CR3：000000002d816000 CR4：000000000003526f0 调用跟踪： <TASK> ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c：900 dev_hard_header include/linux/netdevice.h：3439 [内联] packet_snd net/packet/af_packet.c：3028 [内联] packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c：3108 sock_sendmsg_nosec net/socket.c：727 [内联] __sock_sendmsg net/socket.c：742 [内联]
    ____sys_sendmsg+0xa54/0xc30 net/socket.c：2592 ___sys_sendmsg+0x190/0x1e0 net/socket.c：2646
    __sys_sendmsg+0x170/0x220 net/socket.c：2678 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [内联] do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：
    0033：0x7fe1a0e6c1a9 当非以太网设备（例如 GRE 隧道）从属于绑定时，bond_setup_by_slave（） 会直接将从属设备的header_ops复制到绑定设备：bond_dev->header_ops = slave_dev->header_ops;稍后在绑定设备上调用 dev_hard_header（） 时，这会导致类型混淆。ipgre_header（）、ip6gre_header（） 等函数都使用 netdev_priv（dev） 来访问其设备特定的私有数据。当使用绑定设备调用时，netdev_priv（） 会返回绑定的隐私数据（结构绑定）而非预期的类型（如结构ip_tunnel），从而导致读取垃圾值并导致内核崩溃。通过引入含有封装程序函数的bond_header_ops修复此问题，这些封装程序使用从属设备委托给活动从属header_ops。这可确保从属设备标头函数中的 netdev_priv（） 一律接收正确的设备。该补丁放置在绑定驱动程序中，而不是单个设备驱动程序中，因为根本原因是绑定盲目地从从属设备继承header_ops，而未考虑这些回调预期特定的 netdev_priv（） 布局。通过在 ipgre_header（） 中添加 printk 并运行以下命令可观察到类型混淆： ip link add dummy0 type 虚拟 ip 地址 add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre 本地 10.0.0.1 IP 链接 add bond1 type bond 模式主动备份 ip 链路设置 gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80：：1/64 开发绑定1 （CVE-2026-43456）

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

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

  - net/mlx5e：RX，修复旧版 RQ 的 XDP multi-buf frag 计数 XDP multi-buf 程序可在程序调用 bpf_xdp_pull_data（） 或 bpf_xdp_adjust_tail（） 时修改 XDP 缓冲区的布局。fixes 标签中引用的提交修正了 mlx5 驱动程序中 XDP 缓冲区布局在程序执行期间不会更改的假设。然而，此补丁引入了另一个问题：驱动程序端仍需要统计丢弃的片段，以避免页面片段引用计数问题。使用 3600 负载且缩小 256 字节（即将推出的自我测试修补程序）时，test_xdp_native_adjst_tail_shrnk_data selftest 可观察到此问题：XDP 代码会释放最后一个片段，但驱动程序未对其进行跟踪。这会导致页面释放期间的负pp_ref_count和以下爆裂： WARNING： include/net/page_pool/helpers.h：297 at mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core]， CPU#12： ip/3137 模块链接于： [...]CPU：
    12 UID：0 PID：3137 通信：ip 未受感染 6.19.0-rc3+ #12 无 硬件名称：QEMU 标准 PC（Q35 + ICH9,2009 年），BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 2014 年 4 月 1 日 RIP：
    0010：mlx5e_page_release_fragmented.isra.0+0x4a/0x50 [mlx5_core] [...]调用跟踪： <TASK> mlx5e_dealloc_rx_wqe+0xcb/0x1a0 [mlx5_core] mlx5e_free_rx_descs+0x7f/0x110 [mlx5_core] mlx5e_close_rq+0x50/0x60 [mlx5_core] mlx5e_close_queues+0x36/0x2c0 [mlx5_core] mlx5e_close_channel+0x1c/0x50 [mlx5_core] mlx5e_close_channels+0x45/0x80 [mlx5_core] mlx5e_safe_switch_params+0x1a5/0x230 [mlx5_core] mlx5e_change_mtu+0xf3/0x2f0 [mlx5_core] netif_set_mtu_ext+0xf1/0x230 do_setlink.isra.0+0x219/0x1180 rtnl_newlink+0x79f/0xb60rtnetlink_rcv_msg+0x213/0x3a0 netlink_rcv_skb+0x48/0xf0 netlink_unicast+0x24a/0x350 netlink_sendmsg+0x1ee/0x410 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x232/0x280 ___sys_sendmsg+0x78/0xb0
    __sys_sendmsg+0x5f/0xb0 [...] do_syscall_64+0x57/0xc50 此修补程序通过对所有相关 XDP 操作（XDP_TX、XDP_REDIRECT 和 XDP_PASS）的所有原始 XDP 缓冲区片段执行页面碎片计数来修复此问题。这基本上是恢复到在 fixes 标签中提交之前的原始计数。由于 frag_page 仍然指向原始的尾部，因此需要以不同的方式计算 xdp_update_skb_frags_info（） 的nr_frags参数以反映新的nr_frags。（CVE-2026-43464）

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

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

  - btrfs：修复对收到的子卷进行快照时的事务中止目前，用户可以通过对以前收到的快照进行多次快照直到达到BTRFS_UUID_KEY_RECEIVED_SUBVOL项溢出（叶中可存储的最大项大小）来触发事务中止。这在实践中很可能并不常见，但若发生这种情况，它会把文件系统转变为 RO 模式。快照、发送和set_received_subvol以及subvol_setflags（由接收使用）不需要CAP_SYS_ADMIN，只需inode_owner_or_capable（）即可。恶意用户可利用此问题将文件系统转换为 RO 模式并中断系统。重现脚本：$ cat test.sh #！/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # 使用最小节点大小使测试更快。mkfs.btrfs -f 4K $DEV mount $DEV $MNT # 创建一个子卷并将其设置为 RO 以便可用于发送。 btrfs 子卷 create $MNT/sv touch $MNT/sv/foo btrfs property set $MNT/sv ro true # 将子卷发送和接收到 snaps/sv 中。 mkdir $MNT/snaps btrfs send $MNT/sv | btrfs receive $MNT/snaps # 现在对接收到的子卷进行快照，该子卷有很多次received_uuid，# 次触发叶溢出。 total=500 for （（i = 1; i <= $total; i++））; do echo -ne \r创建快照$i/$total--nodesizebtrfs 子卷快照 -r $MNT/snaps/sv $MNT/snaps/sv_$i > /dev/null done echo umount $MNT 运行测试时：$ ./test.sh （...）创建子卷 '/mnt/sdi/sv' 在子卷 /mnt/sdi/sv 在子卷 sv 创建快照 496/500错误： 无法创建子卷： 定义的数据类型的值过大 创建快照 497/500错误： 无法创建子卷： 只读文件系统 正在创建快照 498/500错误： 无法创建子卷： 只读文件系统正在创建快照 499/500错误： 无法创建子卷： 只读文件系统正在创建快照 499/500错误： 无法创建子卷： 只读文件系统正在创建快照 500/500错误： 无法创建子卷：只读文件系统 且在 dmesg/syslog 中：$ dmesg （...）[251067.627338] BTRFS 警告（设备 sdi）：插入 uuid 项目失败 -75（0x4628b21c4ac8d898、0x2598bee2b1515c91） 类型 252！[251067.629212] ------------[ cut here ]------------ [251067.630033] BTRFS： 事务已中止（错误 -75） [251067.630871] 警告：
    fs/btrfs/transaction.c：1907 at create_pending_snapshot.cold+0x52/0x465 [btrfs]， CPU#10： btrfs/615235 [251067.632851] 链接的模块：btrfs dm_zero （...） [251067.644071] CPU：10 UID：0 PID：615235 comm：
    btrfs 受感染： G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT（full） [251067.646165] 受感染： [W]=WARN [251067.646733] 硬件名称： QEMU Standard PC （i440FX + PIIX， 1996）， BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [251067.648735] RIP：
    0010：create_pending_snapshot.cold+0x55/0x465 [btrfs] [251067.649984] 代码：f0 48 0f （...）[251067.653313] RSP：0018：ffffce644908fae8 EFLAGS：00010292 [251067.653987] RAX：00000000ffffff01 RBX：ffff8e5639e63a80 RCX：00000000ffffffd3 [251067.655042] RDX：ffff8e53faa76b00 RSI：00000000ffffffb5 RDI：ffffffffc0919750 [251067.656077] RBP：ffffce644908fbd8 R08：000000000000000 R09：ffffce644908f820 [251067.657068] R10：
    ffff8e5adc1fffa8 R11： 0000000000000003 R12： ffff8e53c0431bd0 [251067.658050] R13： ffff8e5414593600 R14：
    ffff8e55efafd000 R15：0000000ffffffb5 [251067.659019] FS：00007f2a4944b3c0（0000） GS：ffff8e5b27dae000（0000） knlGS：0000000000000000 [251067.660115] CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 [251067.660943] CR2： 00007ffc5aa57898 CR3： 000000005813a2003 CR4： 00000000000370ef0 [251067.661972] 调用跟踪： [251067.662292] [251067.662653] <TASK> create_pending_snapshots+0x97/0xc0 [btrfs] [251067.663413] btrfs_commit_transaction+0x26e/0xc00 [btrfs] [251067.664257] ？ btrfs_qgroup_convert_reserved_meta+0x35/0x390 [btrfs] [251067.665238] ？ _raw_spin_unlock+0x15/0x30 [251067.665837] ？ record_root_ ---truncated--- （CVE-2026-43361）

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

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

  - drm/panel：修复 jdi_panel_dsi_remove（） 中可能存在的空指针取消引用 在 jdi_panel_dsi_remove（） 中，会明确检查 jdi，表明其可能是 NULL：if （！jdi） mipi_dsi_detach（dsi）;但是，当 jdi 为 NULL 时，该函数不会返回并通过调用 jdi_panel_disable（） 继续执行：err = jdi_panel_disable（&jdi->base）;在 jdi_panel_disable（） 内部，jdi 会被无条件取消引用，这可导致空指针取消引用：struct jdi_panel *jdi = to_panel_jdi（panel）;
    backlight_disable（jdi->背光）;若要避免此潜在空指针取消引用，当 jdi 为 NULL 时，提早从 jdi_panel_dsi_remove（） 返回。(CVE-2026-43300)

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

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

  - drm/amd/display：修复 dsc eDP 问题 [原因] 使用前需要添加函数挂钩检查 （CVE-2026-43320）

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

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

  - mm/vmalloc：防止 RCU 在 kasan_release_vmalloc_node 中停止 启用CONFIG_PAGE_OWNER时，在 vmalloc 清理期间释放 KASAN 影子页面会触发占用大量资源的堆栈展开，从而取得 RCU 读取锁定。
    在未重新安排的情况下处理大型purge_list可造成任务长时间（10+ 秒）占用 CPU，从而导致 RCU 停止并可能出现 OOM 条件。此问题表现在 purge_vmap_node（） -> kasan_release_vmalloc_node（） 中，其中迭代成百上千个vmap_area条目并释放其关联的影子页面会造成：rcu： INFO： rcu_preempt 在 CPU/任务上检测到停止： rcu： 在 0 级rcu_node上阻止的任务 （CPU 0-1）： P6229/1：b.。l ...task：kworker/0:17 state：R 运行任务堆栈：28840 pid：6229 ...kasan_release_vmalloc_node+0x1ba/0xad0 mm/vmalloc.c：2299 purge_vmap_node+0x1ba/0xad0 mm/vmalloc.c：2299 每次调用 kasan_release_vmalloc（） 可释放许多页面，且通过page_owner跟踪，每次释放都会触发 save_stack（），在 RCU 读取锁定下执行堆栈展开。在不让步的情况下，这会创建不受限制的 RCU 关键部分。在循环中添加定期 cond_resched（） 调用，以允许： - 要完成的 RCU 宽限期 - 要运行的其他任务 - 计划程序在需要时抢占该补丁使用 need_resched（） 在负载下立即响应，批次计数 32 作为保证上限，以防止最坏情况的停止（即使在轻负载下）。（CVE-2026-43292）

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

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

  - netfilter：nfnetlink_queue：修复桥接判定错误路径中的条目泄漏 nfqnl_recv_verdict（） 调用 find_dequeue_entry（） 从队列数据结构中删除队列条目，从而获取条目的所有权。对于 PF_BRIDGE 数据包，它随后调用 nfqa_parse_bridge（） 解析 VLAN 属性。如果 nfqa_parse_bridge（） 返回错误（例如，存在NFQA_VLAN但NFQA_VLAN_TCI缺失），该函数会立即返回，而不释放出列条目或其sk_buff。这会泄漏nf_queue_entry、其关联的sk_buff以及所有保留的引用（net_device refcounts、struct net refcount）。反复触发会耗尽内核内存。通过 nfqnl_reinject（） 丢弃条目修复此问题，并在错误路径上进行NF_DROP判定，这与此文件中的其他错误处理一致。（CVE-2026-43451）

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

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

  - x86/apic：如果内核预期，则在恢复时禁用 x2apic 从 s2ram 恢复时，固件可能会重新启用 x2apic 模式，该模式可能在引导期间被内核禁用，原因是其不支持 IRQ 重新映射或者出于其他原因。这导致内核继续使用 xapic 接口，而硬件处于 x2apic 模式，从而导致挂起。这发生在 defconfig + 裸机 + s2ram 上。
    如果内核预期将禁用 x2apic，则在 lapic_resume（） 中将其禁用（即当 x2apic_mode = 0 时），以修复此问题。ACPI v6.6 规范的第 [1] 部分 16.3 表示，固件可还原每个 CPU 的预休眠配置或初始引导配置，包括 MSR 状态：由于从 S2 或 S3 休眠状态唤醒而从开机重置向量执行时，平台固件仅执行将系统还原到初始操作系统引导之前的状态所需的硬件初始化， 或更新为预休眠配置状态。在多处理器系统中，非引导处理器应处于与初始操作系统引导之前相同的状态。（再往前）如果这是 S2 或 S3 唤醒，则平台运行时固件会在跳转到唤醒向量之前还原系统的最小上下文。这包括：CPU 配置。平台运行时固件还原每个 CPU 的预睡眠配置或初始启动配置（MSR、MTRR、固件更新、SMBase 等）。必须禁用中断（对于 IA-32 处理器，通过 CLI 指令禁用）。（和其他事情）因此，至少根据规范，如果 x2apic on 是初始引导配置的一部分，则允许通过固件重新启用 x2apic。[1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization [ bp： 按摩。 ] （CVE-2026-43363）

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

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

  - netfilter：x_tables：保护选项遍历器免受 1 字节末尾读取 当选项的最后一个字节是非单字节选项类型时，以 i += op[i + 1] ？：1 可以读取选项区域末尾后的 op[i + 1]。在 xt_tcpudp 和 xt_dccp 选项遍历器中取消引用 op[i + 1] 之前，添加明确的 i == optlen - 1 检查。（CVE-2026-43452）

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

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

  - libceph：定义并强制执行CEPH_MAX_KEY_LEN 解码密钥时，验证密钥材料是否适合 process_auth_done（） 中的固定大小缓冲区，并且通常是否具有合理的长度。新的CEPH_MAX_KEY_LEN检查取代了对没有密钥材料的密钥的现有检查，后者 a） 不是通用的，因为必须排除CEPH_CRYPTO_NONE，并且 b） 不提供太多值，因为小于所需的密钥与没有密钥一样无效 -- 无论如何这必须在其他地方处理。（CVE-2026-43304）

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

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

  - usb：gadget：f_tcm：修复 nexus 处理中的空指针取消引用 USB Target 驱动程序中的“tpg->tpg_nexus”指针通过 ConfigFS 进行动态管理并关联至用户空间配置。如果 USB 主机在 nexus 完全建立之前或在终止 nexus 之后立即发送请求，则其可能为 NULL。
    目前，“bot_submit_command（）”等函数和数据传输路径会检索“tv_nexus = tpg->tpg_nexus”，并立即取消引用“tv_nexus->tvn_se_sess”，而无任何验证。如果恶意或配置错误的 USB 主机在此争用窗口期间发送 BOT（仅批量传输）命令，就会触发空指针取消引用，从而导致内核错误（本地 DoS）。这暴露出模块内不一致的 API 使用情况，因为对等函数如“usbg_submit_command（）”和“bot_send_bad_response（）”会先正确实现对“tv_nexus”的空检查，然后再继续进行。通过使 nexus 处理保持一致性来修复此问题。将缺少的“if （！tv_nexus）”检查添加到有漏洞的 BOT 命令和请求处理路径，使命令因错误而从容地中止，而不是使系统崩溃。（CVE-2026-43424）

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

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

  - btrfs：修复在集合收到 ioctl 时因项目溢出而造成的事务中止 如果集合接收的 ioctl 在尝试添加BTRFS_UUID_KEY_RECEIVED_SUBVOL时由于项目溢出而失败，我们必须中止事务，因为我们之前执行了一些元数据更新。这意味着如果用户使用许多子卷的相同接收到的 UUID 字段调用此 ioctl，我们将触发溢出，触发事务中止并将文件系统转换为 RO 模式。恶意用户可利用此问题，此 ioctl 甚至不需要用户拥有管理员权限 （CAP_SYS_ADMIN），只需要用户拥有子卷。通过在开始事务之前对项目溢出进行早期检查来修复此问题。这也是争用安全的，因为我们将 subvol_sem 信号量保持在独占（写入）模式下。很快将推出针对 fstests 的测试用例。
    (CVE-2026-43359)

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

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

  - comedi：重新初始化低级驱动程序的附件之间的 dev->spinlock “struct comedi_device”是 COMEDI 子系统所创建的 COMEDI 设备的主要控制结构。它包含包含旋转锁的成员“spinlock”，该旋转锁由 COMEDI 子系统初始化，但保留供附加到 COMEDI 设备的低级驱动程序使用（至少在提交 25436dc9d84f（暂存：comedi：删除 RT 代码）之后）。某些 COMEDI 设备（当 comedi.comedi_num_legacy_minors 参数为非零时，在 COMEDI 子系统初始化时创建的设备）可使用“COMEDI_DEVCONFIG”ioctl 命令在其生命周期内连接到不同的低级驱动程序。这可导致当 COMEDI 设备所连接的每个低级驱动程序使用的旋转锁定锁定级别不匹配时，报告的锁定状态不一致。如果启用了“CONFIG_LOCKDEP”，通过在调用低级驱动程序的“attach”函数指针之前重新初始化“dev->spinlock”来修复此问题。（CVE-2026-43340）

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

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

  - usb：image：mdc800：超时终止下载 URB mdc800_device_read（） 提交download_urb并等待完成。如果超时触发且设备未响应，则该函数返回时不会终止 URB，从而使其保持活动状态。后续 read（） 在相同的 URB 仍在运行时重新提交，从而触发 usb_submit_urb（） 中的 WARN：活动时提交 URB 检查 wait_event_timeout（） 的返回值，如果它指示超时，则终止 URB，确保在检查其状态或重新提交 URB 之前完成。类似于 - 提交 372c93131998（USB：yurex：修复 control-URB 超时处理） - 提交 b98d5000c505（media：rc：iguanair：处理超时）（CVE-2026-43425）

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

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

  - ACPI：processor：修复 acpi_processor_errata_piix4（） 中的空指针取消引用 在 acpi_processor_errata_piix4（） 中，首先为指针 dev 分配一个 IDE 设备，然后重新分配一个 ISA 设备：dev = pci_get_subsys（...， PCI_DEVICE_ID_INTEL_82371AB， ...）;dev = pci_get_subsys（...， PCI_DEVICE_ID_INTEL_82371AB_0， ...）;如果第一次查找成功但第二次失败，则 dev 变为 NULL。
    这导致调用 dev_dbg（） 时可能的空指针取消引用： if （errata.piix4.bmisx） dev_dbg（&dev->dev， ...）;若要避免此情况，请使用两个临时指针并独立检索每个设备，避免用可能的空值覆盖 dev。[ rjw： 主题调整，添加了一个空代码行 ]（CVE-2026-43313）

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

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

  - scsi：hisi_sas：修复 user_scan（） 期间的空指针异常 user_scan（） 为通道 0 调用更新后的 sas_user_scan（），如果成功，则通过提交 37c4e72b0651 中的 scsi_scan_host_selected（） 迭代扫描剩余通道（1 到 shost->max_channel）（scsi：修复 sas_user_scan（） 以处理通配符和多通道扫描）。但是，hisi_sas只支持一个通道，max_channel的当前值为1。
    通道 1 的 sas_user_scan（） 将触发以下空指针异常：[ 441.554662] 无法处理虚拟地址 000000000000008b0 上的内核空指针取消引用 [ 441.554699] 内存中止信息：[441.554710] ESR = 0x0000000096000004 [ 441.554718] EC = 0x25：DABT（当前 EL），IL = 32 位 [441.554723] SET = 0，FnV = 0 [ 441.554726] EA = 0，S1PTW = 0 [ 441.554730] FSC = 0x04：0 级转换错误 [ 441.554735] 数据中止信息：[ 441.554737] ISV = 0， ISS = 0x00000004，ISS2 = 0x00000000 [441.554742] CM = 0，WnR = 0，TnD = 0，TagAccess = 0 [ 441.554747] GCS = 0，Overlay = 0，DirtyBit = 0，Xs = 0 [ 441.554752] 用户可分页：4k 页面，48 位 VA， pgdp=00000828377a6000 [ 441.554757] [000000000000008b0] pgd=0000000000000000，p4d=0000000000000000 [ 441.554769] 内部错误：错误：0000000096000004 [#1] SMP [441.629589] 链接中的模块：arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmuhisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod [ 441.670819] CPU： 46 UID： 0 PID： 6994 Comm： bash Kdump： 已加载 未受感染 7.0.0-rc2+ #84 PREEMPT [ 441.691327] pstate： 81400009 （Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--） [ 441.698277] pc： sas_find_dev_by_rphy+0x44/0x118 [ 441.702896] lr： sas_find_dev_by_rphy+0x3c/0x118 [ 441.707502] sp： ffff80009abbba40 [ 441.710805] x29：
    ffff80009abbba40 x28： ffff082819a40008 x27： ffff082810c37c08 [ 441.717930] x26： ffff082810c37c28 x25：
    ffff082819a40290 x24： ffff082810c37c00 [ 441.725054] x23： 0000000000000000 x22： 0000000000000001 x21：
    ffff082819a40000 [ 441.732179] x20： ffff082819a40290 x19： 000000000000000 x18： 0000000000000020 [441.739304] x17： 000000000000000 x16： ffffb5dad6bda690 x15： 00000000ffffffffff [ 441.746428] x14：
    ffff082814c3b26c x13： 00000000ffffffff x12： ffff082814c3b26a [ 441.753553] x11： 0000000000000000c0 x10：
    000000000000003a x9： ffffb5dad5ea94f4 [ 441.760678] x8： 000000000000003a x7： ffff80009abbbab0 x6：
    0000000000000030 [ 441.767802] x5 ： 0000000000000000 x4 ： 0000000000000000 x3 ： 0000000000000000 [441.774926] x2 ： ffff08280f35a300 x1 ： ffffb5dad7127180 x0 ： 0000000000000000 [ 441.782053] 调用跟踪： [441.784488] sas_find_dev_by_rphy +0x44/0x118 （P） [ 441.789095] sas_target_alloc+0x24/0xb0 [ 441.792920] scsi_alloc_target+0x290/0x330 [ 441.797010] __scsi_scan_target+0x88/0x258 [ 441.801096] scsi_scan_channel+0x74/0xb8 [ 441.805008] scsi_scan_host_selected+0x170/0x188 [ 441.809615] sas_user_scan+0xfc/0x148 [ 441.813267] store_scan+0x10c/0x180 [ 441.816743] dev_attr_store+0x20/0x40 [441.820398] sysfs_kf_write+0x84/0xa8 [ 441.824054] kernfs_fop_write_iter+0x130/0x1c8 [ 441.828487] vfs_write+0x2c0/0x370 [ 441.831880] ksys_write+0x74/0x118 [ 441.835271] __arm64_sys_write+0x24/0x38 [441.839182] invoke_syscall+0x50/0x120 [ 441.842919] el0_svc_common.constprop.0+0xc8/0xf0 [ 441.847611] do_el0_svc+0x24/0x38 [ 441.850913] el0_svc+0x38/0x158 [ 441.854043] el0t_64_sync_handler+0xa0/0xe8 [441.858214] el0t_64_sync+0x1ac/0x1b0 [ 441.861865] 代码： aa1303e0 97ff70a8 34ffff80 d10a4273 （f9445a75） [441.867946] ---[ 结束跟踪 0000000000000000 ]--- 因此 ---truncated--- （CVE-2026-43413）

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

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

  - cpufreq：governor：修复 cpufreq_dbs_governor_init（） 错误路径中的双重释放 当 kobject_init_and_add（） 失败时，cpufreq_dbs_governor_init（） 会调用 kobject_put（&dbs_data->attr_set.kobj）。kobject 释放回调 cpufreq_dbs_data_release（） 调用 gov->exit（dbs_data） 和 kfree（dbs_data），但当前错误路径随后再次调用 gov->exit（dbs_data） 和 kfree（dbs_data），从而导致双重释放。保留 gov->init（） 失败路径的直接 kfree（dbs_data），但调用 kobject_init_and_add（） 之后，让 kobject_put（） 通过 cpufreq_dbs_data_release（） 处理清除。（CVE-2026-43328）

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

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

  - kexec：从符号派生炼狱条目 kexec_load_purgatory（） 通过在 SHF_EXECINSTR 部分内定位 e_entry image->start 来派生 image-start。如果炼狱对象包含多个具有重叠sh_addr的可执行部分，则入口点检查可以匹配多次并触发警告。从purgatory_start符号（如果存在）派生条目部分，并从其最终位置计算 image->start。
    保留不暴露符号的炼狱的现有e_entry回退。警告：
    kernel/kexec_file.c：1009 at kexec_load_purgatory+0x395/0x3c0， CPU#10：kexec/1784 调用跟踪： <TASK> bzImage64_load+0x133/0xa00 __do_sys_kexec_file_load+0x2b3/0x5c0 do_syscall_64+0x81/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e [me@linux.beauty：根据 Baoquan，移动帮助程序以避免转发声明] （CVE-2026-43289）

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

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

  - bpf：正确标记间接跳转的实时寄存器 对于“gotox rX”指令，应将 rX 寄存器标记为已在 compute_insn_live_regs（） 函数中使用。修复此问题。（CVE-2026-43321）

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

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

  - usb：gadget： f_ncm：修复具有 device_move net_device生命周期 在断开连接期间，网络设备的寿命超过其父小工具设备的使用时间，从而导致悬摆 sysfs 链接和空指针取消引用问题。之前尝试通过完全删除 SET_NETDEV_DEV [1] 来解决此问题的尝试由于电源管理排序问题和一个 NO-CARRIER 回归而被恢复。后续尝试推迟将net_device分配给绑定 [2] 1:1 破坏了函数实例与网络设备之间的映射，使 configfs 无法报告已解析的接口名称。这会导致回归，其中 DHCP 服务器在 pmOS 上发生故障。使用device_move跨绑定/取消绑定周期，重新设置小工具设备和 /sys/devices/virtual/ 之间的net_device父级。这样可跨 USB 重新连接保留网络接口，从而允许 DHCP 服务器保留其绑定。引入 gether_attach_gadget（）/gether_detach_gadget（） 帮助程序并在 bind 失败时使用 __free（detach_gadget） 宏撤消附件。bind_count确保 device_move 仅在第一个绑定上执行。[1] https://lore.kernel.org/lkml/f2a4f9847617a0929d62025748384092e5f35cce.camel@crapouillou.net/ [2] https://lore.kernel.org/linux-usb/795ea759-7eaf-4f78-81f4-01ffbf2d7961@ixit.cz/ （CVE-2026-43421）

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

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

  - staging：rtl8723bs：修复 rtw_restruct_wmm_ie 中潜在的越界读取 当前代码检查 if 语句末尾的“i + 5 < in_len”。但它会在该检查之前访问“in_ie[i + 5]”，这可导致越界读取。将长度检查移到条件的开头，以确保访问数组前索引位于边界内。（CVE-2026-43386）

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

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

  - scsi：mpi3mr：重置请求和回复队列时添加 NULL 检查 当回复和请求队列因释放的内存而为 NULL 时，驱动程序会在资源清理期间遭遇崩溃。如果创建回复或请求队列失败，驱动程序首先释放了内存，但尝试内存设置已释放内存的内容，从而导致系统崩溃，那么会发生此问题。在清理期间访问回复/请求内存之前，对回复和请求队列添加空指针检查 （CVE-2026-43473）

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

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

  - i3c：mipi-i3c-hci：修正 DMA 出列中的RING_CTRL_ABORT处理 用于中止 DMA 环的逻辑包含几个缺陷：1.即使环已经停止，驱动程序也会无条件发出环中止。2. 从不重新初始化用于等待中止完成的完成，从而导致错误的等待行为。3. 中止序列会无意间清除RING_CTRL_ENABLE，从而重置硬件环指针并中断控制器状态。4. 如果环已停止，则应将中止操作视为成功，而无需尝试进一步操作。修复中止处理方法，方法是在发出中止前检查环是否正在运行，并在需要时重新初始化完成，确保RING_CTRL_ENABLE在中止期间保持断言状态，并将已停止的环视为成功情况。（CVE-2026-43352）

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

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

  - smb：客户端：修复 SMB2_write（） 中的就地加密损坏 SMB2_write（） 将写入负载作为rq_iov的一部分放置在 iov[1..n] 中。smb3_init_transform_rq（） 指针共享rq_iov，因此 crypt_message（） 就地加密 iov[1]，将原始明文替换为密文。出现可重放的错误时，重试会发送相同的 iov[1]，现在其中包含密文而非原始数据，从而导致损坏。连接不稳定时最容易出现损坏，因为重新连接会触发写入重试，从而重新发送已加密的数据。这会影响 SFU mknod、MF 符号链接等。在之前 6.10 （netfs 转换之前）的内核上，同步写入也使用此路径，并受到类似的影响。
    异步写入路径并非不受影响，因为它使用深层复制的rq_iter。通过 iov_iter_kvec（） 将写入负载移至rq_iter修复，以便 smb3_init_transform_rq（） 在加密前对其进行深层复制。
    (CVE-2026-43362)

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

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

  - net：ncsi：修复错误路径中的 skb 泄漏 NCSI RX 和 AEN 处理程序中的早期返回路径无法释放收到的 skb，从而导致内存泄漏。具体而言，ncsi_aen_handler（） 在不消耗 skb 的情况下返回无效的 AEN 数据包。同样，如果未能解析 NCSI 设备、响应处理程序或请求，ncsi_rcv_rsp（） 会提早退出，从而使 skb 未释放。（CVE-2026-43373）

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

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

  - ASoC：amd：acp-mach-common：为时钟采集添加缺少的错误检查 acp_card_rt5682_init（） 和 acp_card_rt5682s_init（） 函数未检查 clk_get（） 的返回值。这可在时钟核心函数稍后取消引用无效指针时导致内核崩溃。通过以下方式修复此问题： 1.
    将 clk_get（） 更改为设备管理的 devm_clk_get（）。2. 每次时钟采集后立即添加 IS_ERR（） 检查。（CVE-2026-43443）

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

ID	名称	严重性
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
313341	Linux Distros 未修补的漏洞：CVE-2026-43414	critical
313340	Linux Distros 未修补的漏洞：CVE-2026-43428	medium
313339	Linux Distros 未修补的漏洞：CVE-2026-43337	medium
313338	Linux Distros 未修补的漏洞：CVE-2026-43381	medium
313337	Linux Distros 未修补的漏洞：CVE-2026-43411	medium
313336	Linux Distros 未修补的漏洞：CVE-2026-43343	medium
313335	Linux Distros 未修补的漏洞：CVE-2026-43430	medium
313334	Linux Distros 未修补的漏洞：CVE-2026-43319	medium
313333	Linux Distros 未修补的漏洞：CVE-2026-43453	high
313332	Linux Distros 未修补的漏洞：CVE-2026-43317	medium
313331	Linux Distros 未修补的漏洞：CVE-2026-43288	medium
313330	Linux Distros 未修补的漏洞：CVE-2026-43311	medium
313329	Linux Distros 未修补的漏洞：CVE-2026-43447	high
313328	Linux Distros 未修补的漏洞：CVE-2026-43449	high
313327	Linux Distros 未修补的漏洞：CVE-2026-43325	medium
313326	Linux Distros 未修补的漏洞：CVE-2026-43308	medium
313325	Linux Distros 未修补的漏洞：CVE-2026-43456	high
313324	Linux Distros 未修补的漏洞：CVE-2026-43464	high
313323	Linux Distros 未修补的漏洞：CVE-2026-43361	medium
313322	Linux Distros 未修补的漏洞：CVE-2026-43300	medium
313321	Linux Distros 未修补的漏洞：CVE-2026-43320	medium
313320	Linux Distros 未修补的漏洞：CVE-2026-43292	medium
313319	Linux Distros 未修补的漏洞：CVE-2026-43451	medium
313318	Linux Distros 未修补的漏洞：CVE-2026-43363	medium
313317	Linux Distros 未修补的漏洞：CVE-2026-43452	high
313316	Linux Distros 未修补的漏洞：CVE-2026-43304	critical
313315	Linux Distros 未修补的漏洞：CVE-2026-43424	medium
313314	Linux Distros 未修补的漏洞：CVE-2026-43359	medium
313313	Linux Distros 未修补的漏洞：CVE-2026-43340	medium
313312	Linux Distros 未修补的漏洞：CVE-2026-43425	medium
313311	Linux Distros 未修补的漏洞：CVE-2026-43313	medium
313310	Linux Distros 未修补的漏洞：CVE-2026-43413	medium
313309	Linux Distros 未修补的漏洞：CVE-2026-43328	high
313308	Linux Distros 未修补的漏洞：CVE-2026-43289	medium
313307	Linux Distros 未修补的漏洞：CVE-2026-43321	high
313306	Linux Distros 未修补的漏洞：CVE-2026-43421	medium
313305	Linux Distros 未修补的漏洞：CVE-2026-43386	high
313304	Linux Distros 未修补的漏洞：CVE-2026-43473	medium
313303	Linux Distros 未修补的漏洞：CVE-2026-43352	high
313302	Linux Distros 未修补的漏洞：CVE-2026-43362	high
313301	Linux Distros 未修补的漏洞：CVE-2026-43373	high
313300	Linux Distros 未修补的漏洞：CVE-2026-43443	medium

检测

Nessus 的 Misc. 系列

medium

medium

critical

medium

medium

medium

high

medium

critical

medium

medium

medium

medium

medium

medium

medium

high

medium

medium

medium

high

high

medium

medium

high

high

medium

medium

medium

medium

medium

medium

high

critical

medium

medium

medium

medium

medium

medium

high

medium

high

medium

high

medium

high

high

high

medium