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

  - arm64：hibernate：发生错误时恢复 DAIF 状态 Sashiko AI 报告，如果 swsusp_mte_save_tags（） 由于某种原因失败，我们会在掩码 DAIF 的情况下从 swsusp_arch_suspend（） 返回，这不是预期的。从错误路径返回之前还原已保存的 DAIF 状态。（CVE-2026-90290）

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

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

  - ACPI：PCI：清除所有释放 acpi_pci_root acpi_pci_root_add（） 的路径上的driver_data，将新分配的根分配给 dmar_device_add（） 和 pci_acpi_scan_root（） 之前的设备>driver_data。两个失败路径都到达 end： label，其中根是 kfree（）'d，但只有 pci_acpi_scan_root（） 路径首先清除driver_data。当 dmar_device_add（） 在热添加期间失败时，将在设备>driver_data仍指向它时释放根。ACPI 核心在附加失败时未清除driver_data，因此以后的 acpi_pci_find_root（） 调用可能会取消引用此悬摆指针。acpi_pci_root_remove（） 有同样的问题：它释放根而不清除设备>driver_data，从而在删除根桥后留下一个悬摆指针。将空分配移动到共享的 end： 标签，以便在释放根之前清除 acpi_pci_root_add（） 中的每个错误路径driver_data，并在 acpi_pci_root_remove（） 中清除此函数，这样对象在释放后永远也无法通过driver_data访问。（CVE-2026-92521）

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

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

  - smb：client：修复 smb2_new_read_req（） 中的请求缓冲区泄漏 smb2_new_read_req（） 使用 smb2_plain_req_init（） 分配请求缓冲区，但仅将其发布给函数末尾具有 *buf = req 的调用程序。两个错误返回介于两者之间：rc = smb2_plain_req_init（SMB2_READ， io_parms->tcon， server， （void **） &req， total_len）;if （rc） 返回 rc;if （server == NULL） 返回 -ECONNABORTED;[...]rdata->mr = smbd_register_mr（服务器>smbd_conn，&rdata->subreq.io_iter，true，need_invalidate）;if （！rdata->mr） 返回 -EAGAIN;在这两项设备上，缓冲区既不会释放也不会回传，因此会遭到泄露。调用程序无法在其之后进行清理：smb2_async_readv（） 在非零返回时执行“goto out”，这会跳过async_readv_out处的 cifs_small_buf_release（buf），并且在任何情况下都没有在该时分配 buf。写入路径从未出现过此问题。smb2_async_writev（） 内联注册内存区域并跳转到其释放标签而不是返回：wdata->mr = smbd_register_mr（...）;if （！wdata->mr） { rc = -EAGAIN; 转至 async_writev_out; }提交 b7972092199f（cifs：smbd：内存注册失败时重试）在单个修补程序中将两端从 -ENOBUFS 更改为 -EAGAIN，从而使两个形状相邻。实际上只能访问 -EAGAIN 返回，因为 smb2_plain_req_init（） 首先调用 smb2_reconnect（），并且当服务器为 NULL 时，在任何内容被分配之前，这已经因 -EIO 而失败。两种返回在这里都得到了相同的处理，而不是只是偶然地让其中一个正确。由于 -EAGAIN 是一个可重放的错误，该失败还会到达 smb2_async_readv（） 结尾的重试块，该块将子请求标记为NETFS_SREQ_NEED_RETRY，因此可以重试失败的注册，而不是结束 I/O，并且每次尝试到达它都会泄漏另一个缓冲区。
    smb2_should_replay（） 会在 tcon->retry 上短路，因此在硬挂载中，尝试计数不受 retrans 设置的限制。只有异步读取路径会受到影响。同步 SMB2_read（） 调用程序传递 rdata == NULL，且 rdata 上保护内存注册块。Sashiko AI 审阅者在审查与 smb2_async_readv（） 无关的修补程序时指出了内存注册失败路径。（CVE-2026-90125）

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

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

  - Bluetooth： RFCOMM：验证 rfcomm_apply_pn（） 中的 MTU 以防止无限循环 rfcomm_apply_pn（） 接受远程 PN（参数协商）帧的 MTU 值而不检查零。当远程对等端发送零 MTU 时，d->mtu 设置为 0。这会导致 sendmsg 路径在碎片化数据时进入无限循环，因为每个碎片的大小为 == min_t（size_t， len， 0） == 0，因此剩余长度永远不会减少。零长度 skbs 的无限分配耗尽了所有系统内存。通过将协商值为零时将 d->mtu 限制为RFCOMM_DEFAULT_MTU修复，这与 rfcomm_dlc_alloc（） 中分配的初始值一致。（CVE-2026-90088）

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

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

  - platform/surface：acpi-notify：使用前检查 ACPI 配套 由于 device_match_driver_override（） 的原因，可强制每个平台驱动程序匹配与其设备 ID 列表不匹配的设备，因此依赖于设备的 ACPI 配套对象是否存在的平台驱动程序应验证其存在。安装 GSBUS 地址空间处理程序时，san_probe（） 会取消引用 ACPI_COMPANION（） 的结果，因此将驱动程序强制绑定到没有 ACPI 伙伴的设备会导致空指针取消引用。当探测函数从 ACPI_HANDLE（） 切换到 ACPI_COMPANION（） 时引入取消引用。检查 ACPI 伙伴是否有针对 NULL，并在缺少 -ENODEV 时返回 -GENEDEV，如提交 e4865a56d013（ACPI：驱动程序：在探测过程中检查 ACPI_COMPANION） 是否针对 NULL） 对核心 ACPI 平台驱动程序执行的操作。（CVE-2026-93114）

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

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

  - IB/isert：延迟最终登录响应，直到会话注册完成 isert_put_login_tx（） 在 __transport_register_session（） 之前在线上放置最终登录响应，而 iscsi_post_login_handler（） 仅在 iscsi_target_do_login（） 返回后才能到达。发起程序在看到响应后立即发出 SCSI 命令，即可对se_tpg仍为空且 ib-comp-wq 工作因空取消引用而发生错误的se_session执行该命令。哎呀：一般保护错误，可能针对非规范地址 0xdffffc000000000f：0000 [#1] SMP KASAN NOPTI KASAN：范围内的 null-ptr-deref [0x0000000000000078-0x000000000000007f] CPU：0 UID：0 PID：178 通信：kworker/0：1H 未受感染 7.2.0-rc5-V2CTL-gf5098b6bae76 #10 PREEMPT（lazy） 硬件名称：QEMU Ubuntu 24.04 PC v2（i440FX + PIIX，arch_caps补丁，1996 年）、BIOS 1.16.3-debian-1.16.3-2 2014 年 4 月 1 日 工作队列：ib-comp-wq ib_cq_poll_work RIP：
    0010：target_submit+0xbe/0x390 代码： fa 48 c1 ea 03 80 3c 02 00 0f 85 89 02 00 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 64 24 18 49 8d 7c 24 78 48 89 fa 48 c1 EA 03 <80> 3c 02 00 0f 85 5a 02 00 00 48 8d 7b 78 4d 8b 6c 24 78 48 b8 00 RSP： 0018：ffff8881058cfa78 EFLAGS： 00010206 RAX： dffffc0000000000 RBX： ffff88810c78c6f0 RCX： ffffffff964bb363 RDX： 000000000000000f RSI： 00000000fffffe00 RDI： 0000000000000078 RBP：
    1ffff11020b19f52 R08： 0000000000000001 R09： ffffed1020b19f52 R10： 0000000000000003 R11： ffff88810596c000 R12： 000000000000000 R13： ffff88810c61b000 R14： ffff88810c6a3400 R15： ffff88810c61b044 FS：
    000000000000000（0000） GS：ffff8881822b2000（0000） knlGS：0000000000000000 CS：0010 DS：0000 ES：0000 CR0：
    0000000080050033 CR2： 00007f1f1b83c000 CR3： 000000006fe72001 CR4： 0000000000770ef0 PKRU： 55555554 调用跟踪： <TASK> ？ __pfx__raw_spin_lock_bh+0x10/0x10 ？ __pfx_target_submit+0x10/0x10 ？ mutex_lock+0x81/0xe0 ？
    __pfx_mutex_lock+0x10/0x10 ？iscsit_execute_cmd+0x650/0x850 iscsit_sequence_cmd+0x186/0x3d0 iscsit_process_scsi_cmd+0x87/0x300 isert_recv_done+0x1002/0x2390 ？__pfx_isert_recv_done+0x10/0x10 ？rxe_poll_cq+0x253/0x3d0 ？finish_task_switch.isra.0+0x1dc/0xa70 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150 process_one_work+0x633/0x1030 ？assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ？__pfx_worker_thread+0x10/0x10 ？__pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ？recalc_sigpending+0x15c/0x1e0 ？__pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ？
    __pfx_ret_from_fork+0x10/0x10 ？__switch_to+0x572/0xdd0 ？__pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> 链接的模块：---[ end trace 0000000000000000 ]--- 改为延迟最终登录响应。 isert_get_rx_pdu（） 在 conn->rx_login_comp 之后从 iscsi_target_rx_thread（） 运行，在 __transport_register_session（） 之后由 iscsi_post_login_handler（） 完成;iscsi-TCP 和 cxgbit 已从该线程获取 PDU， 单独的 isert 不会。缓冲区仍会首先发布，因此发起程序的第一个命令不符合空的接收队列，没有任何内容取决于 RNR 流控制，而且标头和负载存在于isert_conn中，而不是在 iscsi_target_nego_release（） 首先释放的结构iscsi_login中。在 rxe 上，每次运行 400 个登录周期，oops 出现在 20 次未修补的运行中，有 10 次出现，而且有此修补程序的 20 次运行中没有出现。从不等待的启动程序由下一个修补程序处理。未测试：iWARP、通过 iSER 的发现会话和真实的 HCA。（CVE-2026-90294）

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

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

  - serial：qcom-geni：不推进过时的 DMA 完成 qcom GENI 串行 DMA TX 完成路径将传输 fifo 推进 port->tx_remaining 中记录的字节数。如果 uart_flush_buffer（） 在硬件完成 DMA 传输之后但在处理 DMA 完成中断之前运行，则串行核心会重置传输 fifo，而 port->tx_remaining 仍会描述旧的 DMA 传输。之前的补丁通过检查 fifo 长度是否至少为 tx_remaining，避免推进空 fifo。这仍然无法将旧的 DMA 负载与刷新后写入的新字节区分开来。
    如果用户空间在处理过时的 DMA 完成中断之前写入新数据，fifo 可再次包含至少 tx_remaining 字节，而过时的完成可推进和丢弃这些新字节。刷新传输 fifo 时，将正在传输的 DMA 传输标记为过时。较晚的完成仍未使用保存的长度准备原始 DMA 映射，但不会再推进传输 fifo。
    (CVE-2026-93123)

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

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

  - ntfs：使用 mrec_lock ntfs_read_iomap_begin_resident（） 序列化常驻 iomap 读取在不采用 ni->mrec_lock 的情况下遍历 ntfs_attr_lookup（） -> ntfs_attr_find（），而 ntfs_attr_record_resize（）、ntfs_make_room_for_attr（） 和 ntfs_resident_attr_record_add（） memmove（） 在该锁定下使用相同的 base_ni->mrec 缓冲区。map_mft_record（） 仅采用引用，不进行序列化，因此当写入器重新定位记录时，阅读器可观察到被撕裂的属性长度和偏移字段。KCSAN 报告 mmap 读取错误路径与 link（） 和 unlink（） 之间的争用： 缺陷：KCSAN：
    ntfs_attr_find中的数据争用/通过 CPU 1 上的任务 96 写入 4 字节的0xffff888100af1018 ntfs_attr_record_resize：ntfs_attr_record_resize+0xd2/0x130 ntfs_attr_record_rm+0xad/0x530 ntfs_delete+0x224/0x640 ntfs_unlink+0x14d/0x280 vfs_unlink+0x157/0x520 通过 CPU 0 上的任务 95 读取到 4 个字节的0xffff888100af1018：
    ntfs_attr_find+0x104/0x5b0 ntfs_attr_lookup+0x39c/0x10c0 ntfs_read_iomap_begin_resident+0xc6/0x230 ntfs_read_iomap_begin+0x5d/0xa0 iomap_iter+0x2e2/0x6e0 iomap_read_folio+0x147/0x2a0 ntfs_read_folio+0x108/0x170 filemap_read_folio+0x35/0x100 filemap_fault+0x993/0x1000值已更改：
    0x00000250 -> 0x000001f0 地址为 mrec + 0x18，即 mft_record.bytes_in_use，更改为删除的一个 $FILE_NAME 属性的 96 字节。通过 iomap_end（） 从常驻读取 iomap 查找保留 base_ni->mrec_lock。这样可以保护属性遍历和随后的副本，该副本来自指向 MFT 记录的 iomap->inline_data。不理会非驻留路径：当 ntfs_lookup（） 通过 read_mapping_folio（） 读取索引作品集时，它已经保留了目录 inode 的mrec_lock，并在共享封装程序死锁中通过递归锁定mrec_lock进行锁定。fs/ntfs/dir.c 中 read_mapping_folio（） 调用上方的注释指出了相同的危险。搜索路径使用相同的查找帮助程序，但不会取消引用 iomap->inline_data。在从该路径返回之前释放锁定，而常规读取路径在 iomap->private 中记录base_ni并从其 iomap_end（） 回调释放锁定。使用另一个线程对 16 字节常驻文件运行 link（）/unlink（） 时发生错误的复制器进行测试。之前：大约一秒钟内有 40 个 KCSAN 报告。之后：在 206,090 次读取迭代和 423,540 次链接/断开链接周期中，180 秒内无报告。PROVE_LOCKING版本在相同复制程序运行 60 秒时未显示任何 lockdep 崩溃。（CVE-2026-90131）

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

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

  - Bluetooth：L2CAP：使用针对 l2cap_data 的 proto_lock 修复 l2cap_disconn_ind hci_conn：：l2cap_data 在不锁定的情况下通过 hci_conn_timeout （disc_work） -> hci_proto_disconn_ind -> l2cap_disconn_ind 在 l2cap_disconn_ind 中访问的问题。如果同时删除l2cap_conn，则为 UAF。disc_work在 hci_conn_del（） 中禁用同步，因此无法在disc_work中进行hci_dev_lock。除了使用proto_lock来保护l2cap_data以及保留在其他访问路径中的 hdev->lock 来修复。（CVE-2026-90256）

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

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

  - RDMA/hfi1：在分配失败时保留单元 0 hfi1_free_devdata（） 假设设备已插入单元表并无条件删除 dd->unit。如果 xa_alloc_irq（） 失败，初始化零的单元仍为零，因此完全清除可从索引 0 中删除不相关的设备。仅释放 rdmavt 分配，并在单元表未获取设备时立即返回。（CVE-2026-93103）

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

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

  - ARM：9485/1：mm：针对用户错误获取 show_pte（） 周围的 mmap 写入锁定 设置了 CONFIG_DEBUG_USER=y 并且 cmdline user_debug=31 时，用户错误可在无任何锁定的情况下触发 show_pte（）。如果同一进程中的另一个线程同时调用 munmap（），则可在 show_pte（） 仍在遍历页表页面时释放这些页面，从而导致 show_pte（） 中出现释放后使用。如果 CONFIG_ARM_LPAE=y，则如果在 show_pte（） 运行时释放了 PMD 的页表，这可能会造成内核错误。针对用户错误的 show_pte（） 获取 mmap_write_lock（） 以修复争用。对于用户错误，另外限制仅在地址是用户空间地址时才调用 show_pte（） （地址< TASK_SIZE）。这是因为 tsk->mm 的锁定仅保护用户地址空间的虚拟内存，此外，针对用户错误转储内核空间地址的页面表是不必要的，并且可能存在安全影响。对于内核错误，保持所有内容不变，因为内核已处于 oops 状态，获取锁定有发生死锁的风险。（CVE-2026-90303）

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

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

  - RDMA/mana_ib：部分表插入后耗尽 QP 引用 mana_table_store_ud_qp（） 在插入接收队列 id 之前在其发送队列 id 处发布 QP，从而终止两个 xa_insert_irq（） 调用之间的 XArray 锁定。并行完成处理程序可以查阅 QP 并获取暂时性引用。
    第二次插入失败时，回滚仅擦除发送队列条目并返回，初始表引用和暂时性引用都未完成，而 RDMA 核心会释放 QP，从而造成释放后使用。像正常销毁一样耗尽引用：终止初始引用并等待 qp->free，仅在每次并发查找返回其引用后才释放 QP。（CVE-2026-92513）

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

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

  - wifi：ath11k：修复 ath11k_wmi_process_csa_switch_count_event（） 中的越界读取 WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT没有策略条目，因此解析基础架构不为事件结构强制执行最小长度。此外，num_vdevs字段直接取自固件，并用作绕过vdev_ids数组的循环，而不检查其是否适合 TLV 负载。任一情况都可能导致越界读取。添加用于 WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT的 TLV 策略条目，以便解析基础架构强制使用固定大小事件结构的最小长度。添加辅助函数 ath11k_wmi_tlv_data_len（），以便从已解析 TLV 的数据指针前的标头恢复其负载长度。在 ath11k_wmi_process_csa_switch_count_event（） 中使用它来在循环之前绑定num_vdevs。仅测试编译文件。(CVE-2026-90407)

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

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

  - firmware：arm_scmi：在 TX/RX IDR 中注册通用 BASE 通道或较早协议通道之后，设置失败 scmi_channels_setup（） 时清理通道会失败。通过现有通道清除标签路由此故障，以便在探测错误路径释放 SCMI 实例 ID 之前释放故障前创建的传输通道、传输设备和 IDR 状态。
    (CVE-2026-93090)

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

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

  - liveupdate：记住 FLB retrieve（） 状态 LUO 会跟踪对 FLB 的成功检索尝试。这样做是为了避免多次检索相同的 FLB。多种检索会造成问题，因为一旦检索 FLB，序列化的数据结构可能会被释放，并且 FLB 的状态可能与代码预期的状态非常不同。检索成功时，所有这些操作都会正常进行。如果失败，luo_flb_retrieve_one（） 会立即返回错误，而不会存储任何尝试检索的内容或其错误代码。如果用户尝试检索使用同一 FLB 注册的其他文件，LUO 将再次尝试调用该 FLB 的 retrieve（） 回调。重试存在问题，原因与上文大致相同。FLB 的状态可能与检索逻辑通常预期的状态非常不同（例如，某些 KHO 页面可能已经还原并释放）。没有合理的方法可以再次尝试检索。记住返回的错误检索，并在重试时直接返回它。
    通过将检索到的布尔值更改为retrieve_status整数来实现此操作。值为 0 表示从未尝试检索，正值表示成功，负值表示失败，错误代码为值。这类似于提交 f85b1c6af5bc（实时更新：luo_file：记住 retrieve（） 状态），后者对 LUO 文件执行同样的操作。（CVE-2026-92483）

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

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

  - ubi：修复显式 UBI 设备号的回滚 ubi_init_attach（） 通过扫描 ubi_devices[0..i-1]（） 回滚模块初始化失败，其中 i 是 mtd= 参数索引。这假设参数索引符合 UBI 设备编号。当 mtd= 指定明确ubi_num时，该假设不成立。
    成功连接的设备可以存储在更高的 ubi_devices[] 插槽中，之后发生故障可能会在回滚期间遗漏该设备。扫描整个 ubi_devices[] 数组并按实际数组索引分离，与 UBI 设备的存储方式相匹配。（CVE-2026-90216）

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

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

  - Bluetooth：btmtksdio：修复 TX 路径中的越界 DMA 读取 btmtksdio_tx_packet（） 将传输大小四舍五入为 256 字节的 SDIO 块大小，但按原样向主机控制器传递 SKB 缓冲区：err = sdio_writesb（bdev->func， MTK_REG_CTDR， skb->data， round_up（skb->len， MTK_SDIO_BLOCK_SIZE））;只有 skb->len 字节保存数据包数据，因此控制器最多可读取 255 字节的未初始化内存，并通过 SDIO 总线将其发送到设备。根据 SKB 分配恰好携带的尾室宽松度，该读取也可能延伸到缓冲区末尾之外。预先计算填充长度，确保 SKB 有尾部空间，并使用 skb_put_zero（） 填充填充。skb->len 接着会覆盖填充，因此 sdio_writesb（） 不再需要四舍五入。byte_tx 只会继续计算标头和负载，错误路径会还原 SKB，以便调用方可以重新排队。只有在 skb->tail 后面写入才安全，因为驱动程序拥有缓冲区，Bluetooth：btmtksdio：在 TX 确保之前获取 SKB 的独占所有权。（CVE-2026-90090）

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

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

  - wifi：ath10k：snoc：将 memcpy_fromio（） 用于 MSA ramdump 在 /SNOC 上 WCN3990，MSA 区域与 devm_memremap（MEMREMAP_WT） 映射。在 arm64 上，此类映射无法正常缓存，因此不允许对其进行未对齐访问。ath10k_msa_dump_memory（） 使用经过优化的普通 memcpy（） 复制该区域
    __pi_memcpy_generic实现问题：宽/未对齐的负载。收集 devcoredump 时，这会触发对齐错误 （FSC=0x21） 中的 ath10k_snoc_fw_crashed_dump（） 错误：无法处理内核分页请求... FSC=0x21：对齐错误 PC：__pi_memcpy_generic LR：ath10k_snoc_fw_crashed_dump [ath10k_snoc] Oops 会使固件 RAM 转储缓冲区归零（未捕获转储）并会造成内核崩溃，进而中断调制解调器 SSR 恢复。使用 memcpy_fromio（），它仅执行对此类设备内存映射有效的访问。通用 memcpy_fromio（） 实现在发出字大小的读取之前对齐源，并使用 put_unaligned（） 存储目标，因此对于在非保留内存路径中使用的一致的 DMA 分配也是安全的。ath11k 和 ath12k 将目标内存复制到崩溃转储时使用相同的模式，因此此处也无条件调用。MEMREMAP_WT指针是普通 void *，因此需要显式__iomem转换;使用__force让 Sparse 满意。
    测试时间： WCN3990 hw1.0 SNOC WLAN。HL.3.3.7.c5-00107-QCAHLSWMTPL-1 （CVE-2026-90348）

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

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

  - RDMA/core：修复 counter_release（） 中潜在的释放后使用 当通过 netlink 路径访问计数器时，所述计数器的唯一同步机制为 rdma_restrack_get（）。目前，rdma_restrack_del（） 会在 counter_release（） 的结尾调用，但为时已晚，因为此时可能已经释放与计数器关联的供应商特定资源。这可能会留下一个短暂的窗口，通过重新跟踪仍然可以访问计数器，从而导致潜在的释放后使用。通过将 rdma_restrack_del（） 调用移动到释放供应商特定资源之前修复此问题，确保在释放其内部资源之前从 restrack 中删除计数器。这保证了没有新用户持有对正在销毁的计数器的引用。
    (CVE-2026-92509)

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

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

  - net：page_pool：修复xa_cmpxchg争用的 __page_pool_release_netmem_dma 中的 UAF 此缺陷是在使用 arm64 上的 iperf3 流量的通道重新配置（“ethtool -L”/“ethtool -G”）下测试 hns3 驱动程序时发现的。page_pool_destroy（） 在不同 CPU 上通过 page_pool_put_netmem（） 与页面返回同时运行 page_pool_scrub（） 时，会间歇性触发争用。page_pool_clear_pp_info（） 中的 WARN 浮出水面 cmpxchg 失败者留下的悬摆 DMA 索引位，这导致了调查。
    page_pool_scrub（） 通过不保留页面引用的 xa_for_each（） 迭代池>dma_mapped。
    __page_pool_release_netmem_dma（） 当前在 xa_cmpxchg（） 返回之后读取和写入 netmem 字段（dma_addr、pp_magic 中的 DMA 索引位）。无论 cmpxchg 结果如何，unref 路径都会无条件调用 put_page（）;当它丢失 cmpxchg 时，它仍会在 scrub 获胜者完成这些 netmem 访问之前释放该页面，因此 scrub 会接触一个释放的页面 -- 释放后使用。通过将 DMA 版本拆分为两个函数来修复此问题：1. __page_pool_unmap_netmem_dma（） 在 xa_cmpxchg（） 之前缓存dma_addr，执行 cmpxchg 以删除 DMA 映射，并在缓存地址上调用 dma_unmap。它永远不会接触 cmpxchg 之后的 netmem 字段，因此对于不包含页面引用 2 的 scrub 路径是安全的。
    __page_pool_release_netmem_dma（） 封装上述内容并额外清除 netmem 字段中的 dma_addr 和 DMA 索引位。只有当调用方持有页面引用时才安全，因此返回路径会使用该引用 （page_pool_return_netmem）。scrub 路径直接调用 __page_pool_unmap_netmem_dma（）;返回路径调用 __page_pool_release_netmem_dma（）。（CVE-2026-90201）

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

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

  - platform/x86：asus-wmi：修复探查故障时的资源泄漏 在 asus_wmi_add（） 的驱动程序初始化期间，会依次注册各种子系统。但是，错误路径标签相对于注册顺序是无序的。具体来说：1. 如果 asus_wmi_custom_fan_curve_init（） 失败，驱动程序会跳转到 fail_custom_fan_curve。由于此标签位于 fail_sysfs 下方，因此会绕过之前已成功注册的输入设备和 sysfs 群组的清理调用，从而泄露这些资源。2. 如果 asus_screenpad_init（） 失败，驱动程序将跳转到 fail_screenpad。由于 fail_screenpad 被放置在 fail_backlight 以下，它绕过了对背光和 rfkill 的清理调用，从而泄漏了这些资源。通过对 asus_wmi_add（） 中的错误路径标签重新排序以匹配资源分配的完全相反顺序来修复这些资源泄漏。（CVE-2026-93116）

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

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

  - NFSv4/pnfs：在 NFS 版本 nfs4_pnfs_ds_add（） 上键入数据服务器缓存，键入单独设置的多路径地址上的每网数据服务器缓存，而 struct nfs4_pnfs_ds不记录任何版本。这足以满足始终与版本 4 连接的文件布局驱动程序，但 flexfiles 从每个设备的 GETDEVICEINFO 中获取其版本元组，一个地址可以合法地同时为 NFSv3 和 NFSv4 服务。因此，一个地址上具有不同 ds_versions[0].version 的两个设备 ID 共享一个nfs4_pnfs_ds，而第一个连接的镜像引脚ds_clp到自己的版本。另一个处理器无论如何都会收到该客户端，因此它为连接不会说话的版本选择rpc_call_ops，以及不匹配的序列槽处理取消引用 NULL。将版本添加到缓存密钥中，这样两者就无法使用别名，从而在两个镜像保持可用的同时，为每个版本提供自己的nfs4_pnfs_ds和连接。仅比较主要版本，因为这是选择rpc_call_ops和rpc_ops的;v4.0 和 v4.1 继续共享一个客户端。文件布局驱动程序会传递连接时已进行硬编码的 4。（CVE-2026-90102）

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

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

  - smb：smbdirect：在处理程序锁定之外释放待定子套接字 smbdirect_socket_destroy（） 在仍保留监听器的处理程序锁定的同时释放监听器的待定/就绪子套接字，&id_priv->handler_mutex 通过 rdma_lock_handler（） 获取，而不是 sc->listen.lock，且在监听程序自己的 rdma_destroy_id（） 之前。这种排序有一个真正的后果，一个是表面的。真实的：
    smbdirect_socket_release（） 会终止子进程的最后一个引用，进而破坏子进程的cm_id。在侦听器的 rdma_destroy_id（） 之前执行此操作会使 _cma_cancel_listens（） 从侦听器的
    _destroy_id（），遍历已释放的子id_priv，KASAN 在监听器关机期间将其捕获为 slab-after-free：[ 4758.909130] 缺陷： KASAN：__mutex_lock+0x1469/0x15604758.911450 中的 slab-after-free [] 任务 ksmbd.control/1652 在地址 ffff88821c381db4 读取大小为 1 的 [ 4758.913262] 调用跟踪：
    [ 4758.913267] [ <TASK>4758.913299] __mutex_lock+0x1469/0x1560 [ 4758.913408]
    _cma_cancel_listens+0x312/0x3b0 [ 4758.913413] _destroy_id+0x363/0xee0 [ 4758.913417] smbdirect_socket_destroy_sync+0x17d5/0x2440 [ 4758.913443] smbdirect_socket_release+0x124/0x230 [4758.913451] ksmbd_rdma_stop_listening+0x9f/0x190 [ 4758.913457] ksmbd_conn_transport_destroy+0x65/0x3c0 [4758.913463] kill_server_store+0x1fb/0x2b0 [ 4758.913501] kernfs_fop_write_iter+0x349/0x4d0 [ 4758.913507] vfs_write+0x5e7/0xc70 [ 4758.913528] ksys_write+0x12a/0x210 [ 4758.913541] do_syscall_64+0x135/0x460 [4758.913555] entry_SYSCALL_64_after_hwframe+0x77/0x7f 装饰性的：释放子项递归到 smbdirect_socket_destroy（） 中，这会获取嵌套在监听器下的子项自己的 rdma_lock_handler（） 锁。听者和孩子的cm_id总是不同的实例，因此这不能真正死锁;CM 核心本身在 cma_ib_req_handler（） 中的侦听 ID 下嵌套新连接 ID 的handler_mutex。但 lockdep 只发现一个锁定类，报告可能的递归锁定，然后自行禁用，从而在剩余运行中隐藏真正的锁定缺陷： [ 2424.579653] 警告：检测到可能的递归锁定 [ 2424.581180] 7.1.0-next-20260623+ #89 未受感染 [ 2424.582548]
    -------------------------------------------- [ 2424.584500] ksmbd.control/8854 正在尝试获取锁定：
    [ 2424.586817] ffff888102303c20 （&id_priv->handler_mutex）{+.+.}-{4:4}， at：
    smbdirect_socket_destroy_sync+0xc39/0x2440 [ 2424.590590] 2424.590590[ ] 但任务已保持锁定：
    [ 2424.591601] ffff888102046c20 （&id_priv->handler_mutex）{+.+.}-{4:4}， at：
    smbdirect_socket_destroy_sync+0xc39/0x2440 [ 2424.594178] 2424.594178[ ] 其他可能有助于我们调试此问题的信息：[ 2424.596634] 可能的不安全锁定场景：[ 2424.596634] [ ] 2424.598841CPU0 [2424.599765] ---- [ 2424.600695] 锁（&id_priv->handler_mutex）;[ 2424.601836] 锁（&id_priv->handler_mutex）;[ 2424.602590] [ 2424.602590] *** 死锁 *** [ 2424.602590] [2424.604512] 可能是因为缺少锁定嵌套标记 将挂起/就绪子项拼接到监听器的 listen.lock 下的本地列表，同时保留处理程序锁定，因此并发 CM CONNECT_REQUEST无法添加更多，但会延迟实际的 smbdirect_socket_release（） 调用，直到监听程序的cm_id销毁并其处理程序锁定终止之后。子项是独立的套接字，其拆卸既不需要监听器的处理程序锁定，也不需要其cm_id。在 ksmbdzzer [2] 中发现，KSMBD fuzzer 通过 kcov-dataflow [1] 覆盖向量驱动 libFuzzer：它将每个检测的比较/参数的运行时操作数值及其 PC 一起折叠（默认 arm 将它们混合为 pcval），以便已知站点的新操作数值计为新覆盖率。[1] https://lwn.net/Articles/1077606/ [2] https://github.com/yskzalloc/kcov-dataflow （CVE-2026-90171）

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

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

  - netfilter：nf_tables：跳过元素插入时的双重克隆集表达式。如果未提供替代表达式，设置集合元素表达式时，dynset 和 newsetelem 路径均会复制现有集合表达式。这会导致双重克隆，一次是克隆模板集表达式，然后是新元素上的另一个克隆。添加一个标记以在用户空间提供替代表达式时进行注解（即
    集合类型相同但配置不同的表达式），否则从集合借用现有表达式。如果条件表示替代，则将条件添加到释放表达式。使用此新的 override_exprs 标记将 dynset 表达式替代转储到用户空间。这简化了现有逻辑，并且还修复了 connlimit 表达式的一个缺陷，该缺陷导致在采用默认设置表达式时出现模块引用计数不平衡警告崩溃。（CVE-2026-90061）

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

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

  - net：qlcnic：加载前验证统一的 ROM 部分 统一 ROM 解析器从固件文件中读取目录、产品和数据描述符字段。现有验证表形式表格，数据以未经检查的加法和乘法结尾。畸形值在与固件大小进行对比之前可能会封装。解析器还会在固件控制的偏移处取消引用键入的指针。仅靠有效的描述符范围对于使用者来说是不够的。加载程序会读取固定大小的引导加载程序（无论其声明的大小如何），版本解析器假设末尾为 17 字节，最终部分固件字被读取为完整的 u64。因此，截断映像可使驱动程序在验证或加载期间读取超过固件分配。将指针返回解析器替换为有界范围辅助函数。
    在暴露任何部分之前验证表条目大小、描述符索引、部分范围、固定引导加载程序加载长度以及版本末尾。读取包含未对齐的小端访问器的所有文件字段，并仅从剩余的字节组装部分最终字。在读取旧图像的固定字段之前，对其应用相同的范围检查。（CVE-2026-90112）

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

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

  - HP 已发现并修复 HPLIP 内多个外部报告的漏洞。这些发现影响到多个软件组件，这些组件在某些情况下可能造成远程代码执行、权限升级、拒绝服务、信息泄露或未经授权的文件修改。（CVE-2026-91106）

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

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

  - NFSv4：删除客户端分配失败时的回调 IDR 条目 nfs4_alloc_client（） 在完成客户端设置前分配一个 NFSv4.0 回调标识符。如果以后的任何初始化步骤失败，错误路径会通过 nfs_free_client（） 直接释放nfs_client。这会绕过 nfs_put_client（），正常拆卸期间会删除回调 IDR 条目。因此，失败的分配可使cb_ident_idr指向已释放的nfs_client。cb_ident 稍后的 NFSv4.0 回调查找将找到过时指针并引用它。使回调 IDR 删除帮助程序可由分配失败路径调用，并在释放客户端之前删除回调标识符。这是由本地静态分析检查程序发现的释放前发布生命周期缺陷，并通过手动检查确认。
    (CVE-2026-90151)

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

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

  - nvme-fc：在 init_request __nvme_fc_init_request（） 映射cmd_iu然后rsp_iu DMA  rsp_iu映射失败时取消映射 cmd_iu DMA。如果 rsp_iu 映射失败，原始代码将仅记录错误并失败：它使已映射的cmd_iu未映射，并且在返回之前仍将 op 标记为 FCPOP_STATE_IDLE。由于 .init_request（） 失败时 blk-mq 未调用 .exit_request（），因此会泄漏rsp_iu映射失败的每个 op 的 cmd_iu 映射。在映射失败rsp_iu跳至错误路径，该路径取消映射cmd_iu并在未标记 op 空闲的情况下返回错误，因此它会保持初始 memset（） 设置的FCPOP_STATE_UNINIT状态。（CVE-2026-90411）

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

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

  - usb：修复探测与 dyn ID 删除并发运行时的 UAF 仅当保留了 usb_dynids_lock 时才保证动态 ID 有效，因为 remove_id_store 可以释放节点。因此，请在usb_probe_interface进行复制。
    明确说明 id 参数仅在探测期间有效。USB 序列具有相同的模式，但不需要修复，因为无法通过 sysfs 删除 ID。（CVE-2026-93117）

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

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

  - printk：修复可能的控制台释放后使用 通过旧版打印发出记录时，可能会切换到另一个旧版打印上下文。当上下文执行切换时，会释放控制台 SRCU 读取锁定，并且指向控制台结构的指针现在可能无效。因此，在调用 nbcon_legacy_emit_next_record（） 或 console_emit_next_record（） 后，需要检查 _before_ 是否在进一步@con使用发生了切换。Sashiko 指出 console_flush_one_record（） 没有这样做。在 console_flush_one_record（） 中，发出记录后，在切换检查之后移动 @con 的进一步使用。（CVE-2026-93134）

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

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

  - ARM：9483/1：在 ARM 上选择 HAVE_POSIX_CPU_TIMERS_TASK_WORK Commit c6e61c06d606（ARM：9463/1：允许启用 RT）启用了 PREEMPT_RT，但未选择HAVE_POSIX_CPU_TIMERS_TASK_WORK。这会使 CONFIG_POSIX_CPU_TIMERS_TASK_WORK 处于禁用状态，因此硬 IRQ 上下文中的 CPU 定时器将过期。在PREEMPT_RT这会使 run_posix_cpu_timers（） 采用休眠的 sighand->siglock： 缺陷：从无效上下文 spinlock_rt.c：48 rt_spin_lock从run_posix_cpu_timers run_posix_cpu_timers的lock_task_sighand lock_task_sighand调用的休眠函数 ARM update_process_times处理所有返回用户路径上的TIF_NOTIFY_RESUME， 包括 v7-M。ARM32 提交 541ad0150ca4 删除了 KVM 主机支持（arm：
    删除 32 位 KVM 主机支持），因此选择不必以 KVM 为条件。选择它可将 POSIX CPU 定时器到期延迟到任务上下文。通过 setrlimit（RLIMIT_CPU、...） 与忙碌的循环重现。通过 timer_create（） 创建的 setitimer（ITIMER_PROF 或 ITIMER_VIRTUAL） 和 POSIX CPU 定时器使用相同的路径。
    (CVE-2026-90305)

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

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

  - wifi：mt76：修复 mmio 复制帮助程序 mt76_mmio_write_copy（） 和 mt76_mmio_read_copy（） 迭代到 ALIGN（len， 4） 中的越界访问，因此非 4 的倍数的长度可通过源缓冲区进行读取 （write_copy），或通过目标进行写入 （read_copy）。在循环中复制对齐的正文并通过 4 字节反弹缓冲区处理其余的尾部，同时保持寄存器访问宽度不变。
    (CVE-2026-90369)

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

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

  - hinic3：修复 skb 线性化不匹配问题并在 skb_checksum_help（） 失败时终止 skb 以前，hinic3_send_one_skb（） 会在调用 hinic3_tx_offload（） 之前缓存 skb 片段计数。如果 hinic3_tx_csum（） 回退到不受支持的隧道数据包的 skb_checksum_help（），skb 可能会被线性化。继续使用过时的片段计数构建 TX 描述符将导致描述符不匹配，这可触发越界 DMA 读取或 IOMMU 错误。此外，旧代码忽略 skb_checksum_help（） 的返回值，从而在失败时传输带有不完整校验和的损坏数据包。通过以下方式修复此问题：1. 计算“num_sge”之前移动 hinic3_tx_offload（） 调用，以确保在线性化 SKB 时使用正确的片段计数。2. 传播 skb_checksum_help（） 错误并返回HINIC3_TX_OFFLOAD_INVALID以正确删除 skb。（CVE-2026-90145）

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

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

  - wifi：iwlwifi：防止 iwl_dbg_tlv_alloc_fragments 中发生除以零 确保我们没有以 num_frags = 0 的情况结束。为此，请检查所需的大小是否不是 0，并在num_frags上放置一个检查器。（CVE-2026-93062）

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

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

  - fuse：检查 fuse_fill_super_submount fuse_iget（） 中的 NULL 根 inode 可能在其 inode 分配失败时返回 NULL，但 fuse_fill_super_submount（） 将结果直接传递到 get_fuse_inode（） 并在不进行检查的情况下递减 fi->nlookup：root = fuse_iget（sb， parent_fi->nodeid， ...）;fi = get_fuse_inode（根）;fi->nlookup--;在 fuse_iget（） 中，inode 分配可能失败并返回 NULL。子挂载根采用 iget5_locked（） 路径，其 alloc_inode（） 可能会在内存压力下失败（auto-submount 分支可以在 new_inode（） 或 fuse_alloc_submount_lookup（） 中以相同的方式失败）：inode = iget5_locked（sb， nodeid， fuse_inode_eq， fuse_inode_set， &nodeid）;if （！inode） 返回 NULL;NULL 根使 get_fuse_inode（） 成为 NULL 上的 container_of（），nlookup 递减写入虚假地址，从而造成挂载错误。通过CONFIG_KASAN当自动子挂载的根 inode 分配失败（例如在内存压力下）时，报告了以下空指针取消引用：
    ==================================================================缺陷：KASAN：fuse_get_tree_submount+0x656/0x8b0 中的 null-ptr-deref 按任务 ls/942 在地址 000000000000002b0 读取，大小为 8 CPU：0 PID：942 通信：ls 受感染：G W 6.6 #15 调用跟踪： <TASK> fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 </TASK> ================================================================== 返回 -ENOMEM 代替;调用程序在出错时拆弃部分构建的超级块，从而匹配此函数中的其他错误返回。
    (CVE-2026-90139)

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

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

  - md/raid1：不在 raid1_takeover（） 中设置 array_frozen raid1_takeover（） 会在新分配的 r1conf 上设置 conf->array_frozen = 1，并且无法清除任何内容，因此阵列的每个 I/O 都会永久停止一次
    _wait_barrier（） 发现它卡在 1。这在以前是无害的：level_store（） 在 pers->run（） 之后立即调用 mddev_resume（），后者调用 raid1_quiesce（mddev， 0），并且无论 raid1_takeover（） 设置什么，都将array_frozen清除回 0。提交 b39f35ebe86d（md：不要在 mddev_suspend（）） 中静默）删除了该 quiesce（mddev， 0） 调用，因此现在保留预设。setup_conf（） 已通过 kzalloc 零初始化新的 r1conf，所以不要在此处设置array_frozen。与提交 892da88d1cd9 相同类别的缺陷（md/raid10：
    修复 raid10_takeover（） 中的“conf->barrier”泄漏，同样由 b39f35ebe86d 触发。（CVE-2026-90275）

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

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

  - ACPI：RISC-V：修复 riscv_acpi_add_prt_dep（） 循环处理 riscv_acpi_add_prt_dep（） 中的循环包含错误情况，即使不是完全错误，也会以可疑的方式处理，方法是继续循环（这会跳过并错过指向下一个条目的条目指针更新）。将循环重写为 for 循环（正确处理延续），并使用 helper 函数封装条件和更新语句以使其更整洁。（CVE-2026-93132）

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

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

  - usb：gadget：uac：存储 UAC1 和 UAC2 configfs 之前验证速率列表长度 速率列表属性解析逗号分隔的采样率列表并将每个解析值存储在固定大小的数组中。数组有UAC_MAX_RATES条目，但存储路径在通过 opts->name##s[i++] 写入之前不会检查输入是否最多包含那么多标记。因此，写入超过 10 个速率会在 struct f_uac1_opts 或 struct f_uac2_opts 中写入 or c_srates[] 数组的p_srates[]结尾之后。启用 CONFIG_UBSAN_BOUNDS 时，将 11 条目速率列表写入 UAC1 p_srate 属性报告： UBSAN：
    array-index-out-of-bounds drivers/usb/gadget/function/f_uac1.c：1669：1 索引 10 超出“int [10]”类型的范围 __ubsan_handle_out_of_bounds.cold f_uac1_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 针对 UAC2 p_srate 属性的同一复制器报告： UBSAN： array-index-out-of-bounds drivers/usb/gadget/function/f_uac2.c：2087：1 索引 10 超出“int [10]”类型的范围 __ubsan_handle_out_of_bounds.cold f_uac2_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 在解析UAC_MAX_RATES条目后拒绝其他标记。还保留 kfree（） 的原始 kstrdup（） 指针，因为 strsep（） 会推进解析光标。成功解析时释放高级光标会泄漏原始缓冲区，并可在某些错误路径上释放内部指针。
    (CVE-2026-93122)

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

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

  - sched_ext：直接从 hardlockup 处理程序中止 scx_hardlockup（） 会将中止推迟到irq_work，因为退出声明用于获取scx_sched_lock并且无法从 NMI 运行。现在无需延迟 - 声明是 NMI 安全的，并且断言 ->aborting 正是破坏硬锁定 CPU 的活锁的原因。直接调用 handle_lockup（） 并抛弃irq_work。这也会让自我检测的情况变得可恢复：perf 监视程序会在硬锁定的 CPU 本身上触发，其中排队的 irq_work 永远不会在 IRQ 关闭的情况下运行。还修复返回值：过去在加载sched_ext时返回 %true，从而即使在中止被拒绝时也会抑制内核的硬锁定报告。仅当此调用发起中止时才返回 %true。（CVE-2026-90432）

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

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

  - wifi：mac80211：断开 CSA 与通道 0 的连接 CSA 解析的重构错误地等同于通道零，不存在任何信息，导致其忽略公告切换到该（无效）通道的 AP 上的 CSA。这导致我们不断开连接，这是我们应该的。对于 Intel 设备，这可导致固件崩溃。通过将 int 类型用于通道号和 opclass，并使用无法在元素中编码的（负）值来指示其不存在，从而修复此问题。
    (CVE-2026-90344)

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

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

  - Bluetooth：virtio_bt：避免版本信息字符串的 OOB 读取 virtbt_setup_zephyr（） 发送 Zephyr 供应商命令0xfc08（读取版本信息），并将响应作为以 skb->data + 1 开头的 %s 字符串传递给 bt_dev_info（） 和 hci_set_fw_info（），而不检查长度。以状态回答的后端仅将该指针留在所接收数据的末尾之外，因此遍历会读取相邻的 slab 内存，直到它遇到 NUL。这些字节会到达内核日志和 firmware-info debugfs 文件。要解决此问题，请打印带边界的 %.*s 限制为 skb->len - 1 的字符串。然后，简短或未终止的响应会打印到的数量，而不是设置失败。此镜像提交 dd068ef04412（蓝牙：
    bpa10x：避免 bpa10x_setup（）） 中的修订字符串的 OOB 读取，从而修复相同的模式。
    (CVE-2026-90257)

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

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

  - irqchip/renesas-rzg2l：修复中断丢失 rzg2l_clear_irq_int（） 和 rzg2l_clear_tint_int（） 对 ISCR/TSCR 状态寄存器执行读取-修改-写入以清除刚才处理的中断的位。由于这些寄存器每位写 0 至清除，因此这是争用的：如果另一个中断的状态位设置在读取和写入之间，则该位将由软件构造的值写回为 0，从而清除尚未服务的中断并丢失它。这可以通过一次触发多个中断来重现，例如：gpioset -c gpiochip0 355=0 353=0 328=0 352=0 修复此问题，方法是仅写回正在清除的位，将所有其他位设置为 1，而不是读取-修改-写入整个寄存器。由于硬件保持 1 位不变，因此保留了为其他中断并发设置的状态位。
    (CVE-2026-90124)

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

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

  - coresight：etm4x：修复使用 （nrseqstate - 1） IHI006H 根据嵌入式跟踪宏单元架构规范[0]，仅在TRCIDR5时才会实现 TRCSEQEVR<n> 。NUMSEQSTATE 为 0b100，在这种情况下，n 的范围为 0 到 2;否则，TRCIDR5。NUMSEQSTATE 为 0b000。IOW、初始化中的使用次数或循环中包含 drvdata->nrseqstate - 1 的设置 TRCSEQEVR<n> 可在TRCIDR5时产生下溢问题。NUMSEQSTATE 为 0b000。因此，引入nr_seq_ctrls字段并将其从 nrseqstate 中解除绑定。作为此操作的一部分ETM_MAX_SEQ_TRANSITIONS引入宏并将nr_seq_ctrls及以上宏应用于 TRCSEQEVR<n> 相关字段设置。（CVE-2026-90274）

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

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

  - apparmor：修复不受约束的用户命名空间限制强制堆栈如果任务已受到堆栈的限制，则未正确应用对无约束的非特权转换限制。如果可通过一个不受约束的配置文件执行两个转换，则造成逃逸。通过将检查推送到每个配置文件标签版本中来修复此问题。检查将始终针对未约束执行，并在必要时仅生成未约束组件的堆栈。（CVE-2026-90231）

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

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

  - mtd：mtdswap：避免两次释放已注册的 blktrans 设备 在 mtdswap_add_mtd（） 中，成功注册 blktrans 后的 debugfs 设置失败可释放两次mbd_dev。add_mtd_blktrans_dev（） 初始化 blktrans 设备引用并发布磁盘。一旦成功，del_mtd_blktrans_dev（） 将拆除磁盘并丢弃 blktrans 引用;当该引用达到零时，blktrans_dev_release（） 将释放mtd_blktrans_dev。debugfs 失败路径调用了 del_mtd_blktrans_dev（mbd_dev），然后超出公共清理标签并再次调用了 kfree（mbd_dev）。取消注册后清除本地指针，以便通用清除仍然可以释放 mtdswap 状态，而不会两次释放 blktrans 对象。此问题由静态分析检查程序发现，并经手动源审查确认。（CVE-2026-93049）

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

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

  - cuse：等待模块退出时待定的 RCU 回调 由于提交 053fc4f755ad（fuse：修复 rcu 路径遍历中的 UAF），fuse_conn_put（） 通过 call_rcu（） 释放 fuse_conn，而不是同步释放。对于 cuse，fc->release 是 cuse_fc_release（），它位于 cuse 模块中。如果在 RCU 宽限期结束前删除模块，回调会跳转到已释放的模块内存：userspace / module unload |RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~close（/dev/cuse） |cuse_channel_release（） |fuse_dev_release（） |fuse_conn_put（fch->conn） |call_rcu（delayed_release）
    ------+--->回调排队 |rmmod cuse |cuse_exit（） |cuse_channel_destroy（） |... |返回 | | <module text freed> | | rcu_do_batch（） | delayed_release（） | fc->release（） | -> cuse_fc_release（） | ^^^ 自由文本！vfree（） 未映射释放的模块文本，因此跳转到过时回调会触发页面错误 Oops。如果以后重复使用该虚拟地址，回调可能会执行不相关的代码（未定义的行为）。通过调用 cuse_exit（） 中的 rcu_barrier（） 修复此问题，以便在删除模块之前完成任何待定fuse_conn释放回调。（CVE-2026-90140）

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

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

  - coresight：etm4x：perf 启用中缺少 cscfg_csdev_disable_active_config（） 在 perf 启用路径中，缺少未调用 cscfg_csdev_disable_active_config（） 的情况：- 选择了分支广播，但硬件不支持 - etm4_enable_hw（） 失败 这可导致泄漏 config_desc->active_cnt。通过正确调用这些错误路径中的 cscfg_csdev_disable_active_config（） 修复此问题。（CVE-2026-90273）

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

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

  - wifi：brcmfmac：修复不使用设备 vif 的 P2P 操作帧处理 某些 P2P 操作帧路径假设 P2P 设备 vif 始终可用。当用户空间通过主接口发送非 P2P 公用操作框架，或当操作框架在尚未创建 P2P 设备 vif 后运行时，情况就不正确。在没有 P2P 设备 vif 的情况下中止操作帧时回退到主 vif，并在将 P2P 设备保存的 IE 访问用于对等通道搜索之前保护该访问权限。（CVE-2026-90345）

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

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

  - iommu/tegra241-cmdqv：vSID 只需要一个流 ID tegra241_vintf_init_vsid（） 将客户机 vSID 映射到取自 master->streams[0] 的单个物理流 ID，并且仅在设备没有一个流时发出警告。具有多个流的设备仅映射其第一个流，因此客户机 vSID 无效无法访问其他设备的 ATC 和 IOTLB 条目;带有 None 的设备会使 master->streams 成为ZERO_SIZE_PTR，越界读取。如果 master->num_streams 不是一，则拒绝使用 -EOPNOTSUPP 的映射。
    (CVE-2026-90425)

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

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

  - nfc：nci：修复 nci_data_exchange_complete nci_close_device（） 中的双重完成争用，且 nci_rx_work 可同时调用 nci_data_exchange_complete（）。提交 4527025d440ce8（nfc：nci：修复 nci_close_device 中的循环锁定依赖关系）在 mutex_unlock（&ndev->req_lock） 之后移动了 flush_workqueue（ndev->rx_wq），rx_work不再使用关闭路径中的显式完成调用进行序列化。两个调用程序都读取了非 NULL 回调指针并调用了调用 sock_put（） 的 rawsock_data_exchange_complete（），但只采用了一个 sock_hold（），因此第二个 sock_put（） 使 refcount 下溢并在套接字仍在使用时释放套接字。将裸clear_bit（NCI_DATA_EXCHANGE） 替换为 test_and_clear_bit（），以便只有第一个调用程序继续调用回调。（CVE-2026-90224）

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

ID	名称	严重性
347699	Linux Distros 未修补的漏洞：CVE-2026-90290	medium
347698	Linux Distros 未修补的漏洞：CVE-2026-92521	high
347697	Linux Distros 未修补的漏洞：CVE-2026-90125	medium
347696	Linux Distros 未修补的漏洞：CVE-2026-90088	medium
347695	Linux Distros 未修补的漏洞：CVE-2026-93114	medium
347694	Linux Distros 未修补的漏洞：CVE-2026-90294	high
347693	Linux Distros 未修补的漏洞：CVE-2026-93123	high
347692	Linux Distros 未修补的漏洞：CVE-2026-90131	high
347691	Linux Distros 未修补的漏洞：CVE-2026-90256	high
347690	Linux Distros 未修补的漏洞：CVE-2026-93103	medium
347689	Linux Distros 未修补的漏洞：CVE-2026-90303	medium
347688	Linux Distros 未修补的漏洞：CVE-2026-92513	medium
347687	Linux Distros 未修补的漏洞：CVE-2026-90407	high
347686	Linux Distros 未修补的漏洞：CVE-2026-93090	medium
347685	Linux Distros 未修补的漏洞：CVE-2026-92483	medium
347684	Linux Distros 未修补的漏洞：CVE-2026-90216	high
347683	Linux Distros 未修补的漏洞：CVE-2026-90090	high
347682	Linux Distros 未修补的漏洞：CVE-2026-90348	medium
347681	Linux Distros 未修补的漏洞：CVE-2026-92509	medium
347680	Linux Distros 未修补的漏洞：CVE-2026-90201	high
347679	Linux Distros 未修补的漏洞：CVE-2026-93116	high
347678	Linux Distros 未修补的漏洞：CVE-2026-90102	high
347677	Linux Distros 未修补的漏洞：CVE-2026-90171	medium
347676	Linux Distros 未修补的漏洞：CVE-2026-90061	high
347675	Linux Distros 未修补的漏洞：CVE-2026-90112	high
347674	Linux Distros 未修补的漏洞：CVE-2026-91106	critical
347673	Linux Distros 未修补的漏洞：CVE-2026-90151	critical
347672	Linux Distros 未修补的漏洞：CVE-2026-90411	high
347671	Linux Distros 未修补的漏洞：CVE-2026-93117	medium
347670	Linux Distros 未修补的漏洞：CVE-2026-93134	high
347669	Linux Distros 未修补的漏洞：CVE-2026-90305	medium
347668	Linux Distros 未修补的漏洞：CVE-2026-90369	high
347667	Linux Distros 未修补的漏洞：CVE-2026-90145	high
347666	Linux Distros 未修补的漏洞：CVE-2026-93062	medium
347665	Linux Distros 未修补的漏洞：CVE-2026-90139	medium
347664	Linux Distros 未修补的漏洞：CVE-2026-90275	medium
347663	Linux Distros 未修补的漏洞：CVE-2026-93132	medium
347662	Linux Distros 未修补的漏洞：CVE-2026-93122	high
347661	Linux Distros 未修补的漏洞：CVE-2026-90432	medium
347660	Linux Distros 未修补的漏洞：CVE-2026-90344	medium
347659	Linux Distros 未修补的漏洞：CVE-2026-90257	high
347658	Linux Distros 未修补的漏洞：CVE-2026-90124	high
347657	Linux Distros 未修补的漏洞：CVE-2026-90274	medium
347656	Linux Distros 未修补的漏洞：CVE-2026-90231	high
347655	Linux Distros 未修补的漏洞：CVE-2026-93049	medium
347654	Linux Distros 未修补的漏洞：CVE-2026-90140	high
347653	Linux Distros 未修补的漏洞：CVE-2026-90273	medium
347652	Linux Distros 未修补的漏洞：CVE-2026-90345	medium
347651	Linux Distros 未修补的漏洞：CVE-2026-90425	high
347650	Linux Distros 未修补的漏洞：CVE-2026-90224	high

检测

Nessus 的 Misc. 系列

medium

high

medium

medium

medium

high

high

high

high

medium

medium

medium

high

medium

medium

high

high

medium

medium

high

high

high

medium

high

high

critical

critical

high

medium

high

medium

high

high

medium

medium

medium

medium

high

medium

medium

high

high

medium

high

medium

high

medium

medium

high

high