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

  - mediaas102进行修复以在 as102_usb_probe() 中注册设备后不释放内存。在 as102_usb 驱动程序中会发生以下争用条件“ CPU0 CPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); fd = sys_open(/path/to/dev); // open as102 fd ....
    usb_deregister_dev(); .... kfree(); // 释放 as102_dev_t .... sys_close(fd); as102_release() // UAF as102_usb_release() kfree(); // DFB '' 当后来取消注册使用 usb_register_dev() 的 USB 字符设备通过 usb_deregister_dev() 或 disconnect 时设备节点将被删除因此新的 open() 调用失败。但是已打开的文件描述符不会立即消失它们会一直保持有效直到放弃最后一个引用并调用驱动程序的 .release()。在 as102 中as102_usb_probe() 调用 usb_register_dev()然后在错误路径上执行 usb_deregister_dev() 并立即释放 as102_dev_t。如果用户空间在取消注册前与成功的 open() 争用则打开的 FD 将在稍后命中 as102_release() --> as102_usb_release() 并访问或再次释放 as102_dev_t发生争用释放后使用和双重释放的漏洞。此项修复为在 usb_register_dev() 成功后永不直接使用 kfree(as102_dev_t)。取消注册后将内存释放推迟到 .release()。换句话说当关闭最终打开的 FD 时让 release() 执行最后一个 kfree。 (CVE-2026-31578)

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

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

  - ocfs2修复 unlink 和 dio_end_io_write 之间可能的死锁 ocfs2_unlink 首先采用孤立的目录 inode_lock然后采用 ip_alloc_sem而在 ocfs2_dio_end_io_write 中它以相反的顺序获取这些锁定。
    这会在锁定类 ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] 和 ocfs2_file_ip_alloc_sem_key 上创建 ABBA 锁定排序冲突。Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock B Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock )ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- 锁定 B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- 锁定 A 死锁情况CPU0unlinkCPU1 (dio_end_io_write) ------ ------ inode_lock orphan_dir_inodedown_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode) 由于 ip_alloc_sem 是为了保护分配更改与 ocfs2_del_inode_from_orphan 中的操作无关。因此将 ocfs2_del_inode_from_orphan 移出 ip_alloc_sem 以修复死锁。 (CVE-2026-31598)

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

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

  - 已修复 Linux 内核中的下列漏洞：clockevents: Add missing resets of the next_event_forced flag The prevention mechanism against timer interrupt starvation missed to reset the next_event_forced flag in a couple of places: - When the clock event state changes. That can cause the flag to be stale over a shutdown/startup sequence - When a non-forced event is armed, which then prevents rearming before that event. If that event is far out in the future this will cause missed timer interrupts. - In the suspend wakeup handler. That led to stalls which have been reported by several people. Add the missing resets, which fixes the problems for the reporters. (CVE-2026-31574)

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

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

  - smb：客户端：修复 OOB 读取解析符号链接错误响应 当 CREATE 返回 STATUS_STOPPED_ON_SYMLINK 时，smb2_check_message（） 会返回成功而不进行任何长度验证，从而使符号链接解析器成为抵御不受信任服务器的唯一防御措施。symlink_data（） 遍历循环测试 p 结束< SMB 3.1.1 错误上下文，但在偏移 4 处读取 p->ErrorId，在偏移 0 处读取 p->ErrorDataLength。当服务器控制的 ErrorDataLength 将 p 前进到 end 的 1-7 字节以内时，下一次迭代将读取它。找到匹配的上下文后，sym->SymLinkErrorTag 会在偏移 4 处从 p->ErrorContextData 读取，而不检查 symlink 标头本身是否适合。然后，smb2_parse_symlink_response（） 会使用SMB2_SYMLINK_STRUCT_SIZE作为 PathBuffer 从 iov_base 的偏移量，对替代名称进行边界检查。该值的计算公式为 sizeof（smb2_err_rsp） + sizeof（smb2_symlink_err_rsp），仅当 ErrorContextCount == 0 时才正确。
    至少有一个错误上下文时，符号链接数据的字节深度会增加 8 个字节，并且每个跳过的非匹配上下文都会将其进一步移动 8 + ALIGN（ErrorDataLength， 8）。检查太短，允许替代名称读取超过iov_len。越界堆字节经过 UTF-16 解码成符号链接目标，并通过 readlink（2） 返回至用户空间。修复了这一切，方法是使循环测试需要适合完整的上下文标头，拒绝其标头跑过尾的符号，并将替代名称绑定到 sym->PathBuffer 的实际位置，而非固定的偏移。因为 sub_offs 和 sub_len 都是 16 位，所以指针数学不会在这里溢出新的 greater-than。（CVE-2026-31613）

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

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

  - PCI端点pci-epf-vntb停止 epf_ntb_epc_cleanup 中的 cmd_handler 工作在清除 BAR 映射和 doorbells 之前禁用延迟的工作以避免在移除资源后运行处理程序。
    无法处理虚拟地址 ffff800083f46004 处的内核分页请求 [...] 内部错误Oops
    0000000096000007 [#1] SMP [...] 调用跟踪epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20 (CVE-2026-31595)

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

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

  - batman-adv通过引用保留声明backbone 网关 batadv_bla_add_claim() 可替换claim->backbone_gw 并终止旧网关的上一个引用当读取器仍然跟随指针时。netlink 声明转储路径取消引用claim->backbone_gw->orig 并采用claim->backbone_gw->crc_lock而不固定底层主干网关。 batadv_bla_check_claim() 仍然具有相同的裸指针访问模式。在两个阅读器中重新使用 batadv_bla_claim_get_backbone_gw() 以便它们在稳定的网关引用上运行直到读取端工作完成。这可使转储和声明检查路径与为其他 BLA 声明阅读程序引入的生命周期规则保持一致。 (CVE-2026-31657)

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

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

  - media：mediatek：vcodec：修复编码器版本路径中的释放后使用 fops_vcodec_release（） 函数释放上下文结构 （ctx），而无需首先取消 ctx->encode_work 中的任何待定或正在运行的工作。这将创建一个争用窗口，工作队列处理程序 （mtk_venc_worker） 在释放上下文内存后可能仍在访问上下文内存。争用条件：CPU 0（释放路径） CPU 1（工作队列） --------------------- ------------------ fops_vcodec_release（） v4l2_m2m_ctx_release（） v4l2_m2m_cancel_job（） // 等待 m2m 作业完成 mtk_venc_worker（） v4l2_m2m_job_finish（） // m2m 作业完成 // 但工作仍在运行！ post-job_finish access：其他 ctx 取消引用 // 如果 ctx 已释放则为 UAF // 返回（作业完成） kfree（ctx） // ctx 已释放 根本原因：v4l2_m2m_ctx_release（） 仅等待 m2m 作业生命周期（通过TRANS_RUNNING标记），而不等待工作队列生命周期。调用 v4l2_m2m_job_finish（） 后，m2m 框架会认为作业完成并返回 v4l2_m2m_ctx_release（），但工作线程函数会继续执行，并且可能仍会访问 ctx。在编码操作期间，工作通过以下方式排队：queue_work（ctx->dev->encode_workqueue， &ctx->encode_work） 工作线程函数会访问 ctx->m2m_ctx、ctx->dev 和其他 ctx 字段，即使在调用 v4l2_m2m_job_finish（） 之后也是如此。通过运行可扩大 post-job_finish 争用窗口的检测测试模块，KASAN 已确认此漏洞。KASAN 检测到：缺陷：KASAN：mtk_venc_worker+0x159/0x180 中的释放后使用 任务 kworker/u8：0/12 在地址 ffff88800326e000 处读取了大小为 4 的工作队列：mtk_vcodec_enc_wq mtk_venc_worker 按任务 47 分配：__kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0 由任务 47 释放：__kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190 通过在调用 kfree（ctx） 之前调用 cancel_work_sync（&ctx->encode_work） 来修复此问题。这可确保在释放上下文之前取消工作队列处理程序（如果待处理）和同步（等待任何正在运行的处理程序完成）。放置理由：该补丁位于 v4l2_ctrl_handler_free（） 之后和 list_del_init（&ctx->list） 之前。此时，所有 m2m 操作已完成（v4l2_m2m_ctx_release（） 已返回），我们需要确保工作队列已同步，然后再从列表中删除 ctx 并将其释放。注意：打开错误路径不需要 cancel_work_sync（），因为 INIT_WORK（） 只是初始化工作结构，它不会对其进行计划。稍后在 device_run（） 操作期间才会安排工作。（CVE-2026-31584）

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

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

  - 已修复 Linux 内核中的下列漏洞：bnge: return after auxiliary_device_uninit() in error path When auxiliary_device_add() fails, the error block calls auxiliary_device_uninit() but does not return. The uninit drops the last reference and synchronously runs bnge_aux_dev_release(), which sets bd->auxr_dev = NULL and frees the underlying object. The subsequent bd->auxr_dev->net = bd->netdev then dereferences NULL, which is not a good thing to have happen when trying to clean up from an error. Add the missing return, as the auxiliary bus documentation states is a requirement (seems that LLM tools read documentation better than humans do...) (CVE-2026-31621)

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

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

  - ocfs2：处理无效的 dinode ocfs2_group_extend [BUG] fs/ocfs2/resize.c：308！ 的内核缺陷哎呀：
    无效操作码： 0000 [#1] SMP KASAN NOPTI RIP： 0010：ocfs2_group_extend+0x10aa/0x1ae0 fs/ocfs2/resize.c：308 Code： 8b8520ff ffff83f8 860f8580 030000e8 5cc3c1fe 调用跟踪： ...ocfs2_ioctl+0x175/0x6e0 fs/ocfs2/ioctl.c：869 vfs_ioctl fs/ioctl.c：51 [内联] __do_sys_ioctl fs/ioctl.c：597 [内联]
    __se_sys_ioctl fs/ioctl.c：583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c：583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h：17 do_syscall_x64 arch/x86/entry/syscall_64.c：63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c：94 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... [原因] ocfs2_group_extend（） 假设从 ocfs2_inode_lock（） 返回的全局位图 inode 块已经过验证，并在签名不是 dinode 时BUG_ONs。这个假设对于构建的文件系统来说太强了，因为 JBD2 管理的缓冲区路径可绕过结构验证并返回无效的 dinode 给调整大小的 ioctl。[修复]在 ocfs2_group_extend（） 中显式验证 dinode。如果全局位图缓冲区不包含有效的 dinode，请使用 ocfs2_error（） 报告文件系统损坏并使调整大小操作失败，而不是造成内核崩溃。（CVE-2026-31596）

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

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

  - usb：gadget：f_hid：使用 cdev 时不调用 cdev_init 调用 unbind 然后再次绑定时，cdev_init 重新初始化 cdev，即使可能仍有对它的引用。当 /dev/hidg* 设备仍处于打开状态时便会出现此情况。这种明显不安全的行为，就像 oopes 一样。这通过使用 cdev_alloc 将 cdev 放在堆上修复了此问题。这样，我们就可以在hidg_bind中简单地分配一个新的。
    (CVE-2026-31606)

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

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

  - nfcllcp添加 LLCP_CLOSED 检查后缺少的返回 在 nfc_llcp_recv_hdlc() 和 nfc_llcp_recv_disc() 中当套接字状态为 LLCP_CLOSED时代码会正确调用 release_sock() 和 nfc_llcp_sock_put() 但无法返回。执行继续进行到函数的剩余部分从而再次调用 release_sock() 和 nfc_llcp_sock_put()。这将导致通过双重 nfc_llcp_sock_put() 造成的双重 release_sock() 和引用计数下溢从而导致释放后使用。在两个函数的 LLCP_CLOSED 分支后添加缺失的 return 语句以防止 fall-through。 (CVE-2026-31629)

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

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

  - batman-adv：拒绝过大的全局 TT 响应缓冲区 batadv_tt_prepare_tvlv_global_data() 在 16 位临时变量中构建全局 TT 响应的分配长度。当远程创建者通告足够大的全局 TT 时，TT 负载长度加上 VLAN 标头偏移可超过 65535 并在 kmalloc() 之前换行。全表响应路径在填充 tt_change 时仍使用原始 TT 负载长度，因此封装的分配太小，batadv_tt_prepare_tvlv_global_data() 在后面的数据包大小检查运行之前，写入超过了堆对象的末尾。通过拒绝 TVLV 值的长度不适合 16 位 TVLV 负载长度字段的 TT 响应修复此问题。 (CVE-2026-31659)

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

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

  - ksmbd当令牌分配后 SPNEGO 解码失败时修复 mechToken 泄漏 内核 ASN.1 BER 解码器在遍历输入时会增量调用操作回调。当 ksmbd_decode_negTokenInit() 到达 mechToken [2] OCTET STRING 元素时ksmbd_neg_token_alloc() 会通过 kmemdup_nul() 立即分配 conn->mechToken。如果同一 blob 中更新的元素格式错误则解码器将在分配生效后返回非零。如果 mechListMIC [3] 溢出封闭的 SEQUENCE 则可发生这种情况。 decode_negotiation_token() 然后设置 conn->use_spnego = false因为 negTokenInit 和 negTokenTarg 语法失败。smb2_sess_setup() 底部的清理在 use_spnego 上关闭 if (conn->use_spnego && conn->mechToken) { kfree(conn->mechToken); conn->mechToken = NULL;因此会跳过 kfree 从而导致永远不会释放 mechToken。此代码路径在预身份验证前可访问因此不受信任的客户端即使在未经正确身份验证的情况下也可在服务器上造成缓慢的内存泄漏。通过不执行 use_spnego 修复此问题因为不需要这样内存将始终得到正确释放。同时始终释放 ksmbd_conn_free() 中的内存以防万一其他某些故障路径忘记释放内存。 (CVE-2026-31610)

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

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

  - mmc：vub300：修复断开连接时的空取消引用 确保在断开连接时放弃对驱动程序数据的引用前取消注册控制器，以避免空指针取消引用或释放后使用。
    (CVE-2026-31651)

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

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

  - usb：gadget：renesas_usb3：验证标准请求处理程序中的端点索引 GET_STATUS 和 SET/CLEAR_FEATURE 处理程序从主机提供的 wIndex 中提取端点编号，而不需要任何验证。在尝试根据此数学计算取消引用指针之前，验证与设备拥有的端点数量实际匹配的端点数量，来修复此问题。这就像在对 aspeed 驱动程序提交 ee0d382feb44（usb：gadget：aspeed_udc：验证 ast udc 的端点索引）中的操作一样。（CVE-2026-31615）

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

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

  - SMB：服务器：让send_done处理完成而不IB_SEND_SIGNALED通过smbdirect_send_batch处理，我们很可能有没有IB_SEND_SIGNALED的请求，这些请求会在IB_SEND_SIGNALED设置的最终请求中被销毁。如果连接断开，所有请求都会被发出信号，即使没有显式的 IB_SEND_SIGNALED。（CVE-2026-31536）

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

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

  - ASoC：qcom：q6apm：将组件注册移动到非受管版本 q6apm 组件从 ASoC 拓扑动态注册 dai，使用设备受管版本 API 进行分配。使用托管版本同时分配组件和动态 dai 可导致错误的释放排序，当组件仍保留对 dai 的引用时，dai 将被释放。通过将组件移动到未管理版本修复此问题，以便仅在删除组件后才释放 dai 指针。
    ================================================================== 缺陷：KASAN：snd_soc_del_component_unlocked+0x3d4/0x400 中的 slab-after-free [snd_soc_core] 任务 kworker/u48：0/3426 在地址 ffff00084493a6e8 读取大小为 8 受感染：[W]=WARN 硬件名称：LENOVO 21N2ZC5PUS/21N2ZC5PUS，BIOS N42ET57W （1.31 ） 2024/08/08 工作队列：pdr_notifier_wq pdr_notifier_work [pdr_interface] 调用跟踪：show_stack+0x28/0x7c （C） dump_stack_lvl+0x60/0x80 print_report+0x160/0x4b4 kasan_report+0xac/0xfc
    __asan_report_load8_noabort+0x20/0x34 snd_soc_del_component_unlocked+0x3d4/0x400 [snd_soc_core] snd_soc_unregister_component_by_driver+0x50/0x88 [snd_soc_core] devm_component_release+0x30/0x5c [snd_soc_core] devres_release_all+0x13c/0x210 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr]device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 按任务 77 分配：kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x44/0x58 __kasan_kmalloc+0xbc/0xdc __kmalloc_node_track_caller_noprof+0x1f4/0x620 devm_kmalloc+0x7c/0x1c8 snd_soc_register_dai+0x50/0x4f0 [snd_soc_core] soc_tplg_pcm_elems_load+0x55c/0x1eb8 [snd_soc_core] snd_soc_tplg_component_load+0x4f8/0xb60 [snd_soc_core] audioreach_tplg_init+0x124/0x1fc [snd_q6apm] q6apm_audio_probe+0x10/0x1c [snd_q6apm] snd_soc_component_probe+0x5c/0x118 [snd_soc_core] soc_probe_component+0x44c/0xaf0 [snd_soc_core] snd_soc_bind_card+0xad0/0x2370 [snd_soc_core] snd_soc_register_card+0x3b0/0x4c0 [snd_soc_core] devm_snd_soc_register_card+0x50/0xc8 [snd_soc_core] x1e80100_platform_probe+0x208/0x368 [snd_soc_x1e80100] platform_probe+0xc0/0x188 really_probe+0x188/0x804 __driver_probe_device+0x158/0x358 driver_probe_device+0x60/0x190 __device_attach_driver+0x16c/0x2a8 bus_for_each_drv+0x100/0x194
    __device_attach+0x174/0x380 device_initial_probe+0x14/0x20 bus_probe_device+0x124/0x154 deferred_probe_work_func+0x140/0x220 process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 由任务 3426 释放：kasan_save_stack+0x40/0x68 kasan_save_track+0x20/0x40 __kasan_save_free_info+0x4c/0x80 __kasan_slab_free+0x78/0xa0 kfree+0x100/0x4a4 devres_release_all+0x144/0x210 device_unbind_cleanup+0x20/0x190device_release_driver_internal+0x350/0x468 device_release_driver+0x18/0x30 bus_remove_device+0x1a0/0x35c device_del+0x314/0x7f0 device_unregister+0x20/0xbc apr_remove_device+0x5c/0x7c [apr] device_for_each_child+0xd8/0x160 apr_pd_status+0x7c/0xa8 [apr] pdr_notifier_work+0x114/0x240 [pdr_interface] process_one_work+0x500/0xb70 worker_thread+0x630/0xfb0 kthread+0x370/0x6c0 ret_from_fork+0x10/0x20 （CVE-2026-31587）

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

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

  - nilfs2修复 nilfs_mdt_save_to_shadow_map 中的空 i_assoc_inode 取消引用。DAT inode 的 btree 节点缓存 (i_assoc_inode) 在 btree 操作期间延迟初始化。但是当nilfs_mdt_save_to_shadow_map() 在 GC 期间将脏页复制到阴影贴图时假定 i_assoc_inode 已初始化。如果在挂载之后在 DAT inode 上发生任何 btree 操作之前立即调用 NILFS_IOCTL_CLEAN_SEGMENTS则 i_assoc_inode 为 NULL从而导致一般保护错误。修复方法是在挂载时对 nilfs_dat_read() 中的 DAT inode 调用 nilfs_attach_btree_node_cache()确保 i_assoc_inode 始终在任何 GC 操作可以使用之前初始化。 (CVE-2026-31577)

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

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

  - ksmbd：读取前需要3个子权限sub_auth[2]parse_dacl（）将每个ACE SID与sid_unix_NFS_mode进行比较，匹配时读取sid.sub_auth[2]作为文件模式。如果sid_unix_NFS_mode是前缀S-1-5-88-3，且num_subauth = 2，则compare_sids（）只比较最小（num_subauth， 2）个子权威，因此客户端SID的num_subauth = 2且 sub_auth = {88， 3}将匹配。如果num_subauth = 2，且ACE位于安全描述符的最末端，sub_auth[2]将比end_of_acl晚4字节。带外字节随后会被屏蔽到低9位，并作为文件的POSIX模式应用，这可能不是好事。通过强制SID在阅读前必须先承载第三个子权威来解决这个问题。（CVE-2026-31611）

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

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

  - ksmbd验证 smb2_get_ea() 中的 EaNameLength smb2_get_ea() 读取 ea_req->EaNameLength 从客户端请求中直接传递至 strncmp() 作为比较长度而不验证名称的长度是否确实为接收到的输入缓冲区的大小。通过根据接收到的值和请求的总体大小正确检查名称的大小来修复此问题从而防止之后的 strncmp() 调用将长度用作缓冲区的可信大小。如果不进行此检查未初始化的堆值可能会缓慢地泄露给客户端。 (CVE-2026-31612)

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

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

  - staging：rtl8723bs：初始化 rtw_BIP_verify（） 中的 le_tmp64 将 rtw_BIP_verify（） 中的 le_tmp64 初始化为零以防止使用未初始化的数据。Smatch 警告，只有 6 个字节会复制到这个 8 字节 （u64） 变量，而最后两个字节处于未初始化状态：
    drivers/staging/rtl8723bs/core/rtw_security.c：1308 rtw_BIP_verify（） 警告：未为“&le_tmp64”复制足够的字节（8 字节与 6 字节） 初始化函数开头的变量可修复此警告并确保行为可预测。（CVE-2026-31626）

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

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

  - Deskflow 是一款键盘和鼠标共享应用程序。在之前 1.26.0.138，Deskflow 剪贴板反序列化中的远程内存安全漏洞允许连接的对等方通过发送格式错误的剪贴板更新触发越界读取。src/lib/deskflow/IClipboard.cpp 的实现中存在问题。这是可访问的，因为 src/lib/deskflow/ClipboardChunk.cpp 中的 ClipboardChunk：：assemble（） 仅验证外部剪贴板传输大小。它不会验证序列化剪贴板 blob 的内部结构，因此畸形内部长度可以未更改地到达 IClipboard：：unmarshall（）。此漏洞已在 1.26.0.138 中修复。(CVE-2026-41476)

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

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

  - FreeRDP 是远程桌面协议的免费实现。在低于 3.25.0 的版本中在“channels/drive/client/drive_file.c”的路径遍历过滤器中存在一个差一错误。“contains_dotdot()”函数捕获“../”和“..\”中间路径但缺少“..”当“..”是最后一个无结尾分隔符的组件时。
    流氓 RDP 服务器可通过 RDPDR 请求读取、列出或写入客户端共享文件夹上一级目录的文件。受害者需要在启用驱动器重定向的情况下进行连接。版本 3.25.0 针对此问题提供了补丁。(CVE-2026-40254)

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

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

  - NET：lan966x：修复page_pool lan966x_fdma_rx_alloc_page_pool（） page_pool_create（）中的错误处理，故障时可返回ERR_PTR。返回值在随后的循环中无条件使用，将错误指针通过xdp_rxq_info_reg_mem_model（）进入page_pool_use_xdp_mem（），从而去参照，导致核失误。在page_pool_create（）后加一个IS_ERR检定，以便在失败时提前返回。
    (CVE-2026-31646)

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

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

  - 已修复 Linux 内核中的下列漏洞：smb: server: avoid double-free in smb_direct_free_sendmsg after smb_direct_flush_send_list() smb_direct_flush_send_list() already calls smb_direct_free_sendmsg(), so we should not call it again after post_sendmsg() moved it to the batch list.
    (CVE-2026-31608)

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

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

  - net：lan966x：修复错误路径中的页池泄漏 lan966x_fdma_rx_alloc（） 创建页池，但是在后续 fdma_alloc_coherent（） 调用失败时不会破坏该页池从而导致泄漏池。同样，当 lan966x_fdma_tx_alloc（） 失败时，lan966x_fdma_init（） 将释放一致的 DMA 内存，但不会破坏由 lan966x_fdma_rx_alloc（） 成功创建的页池，从而泄露该池。添加两个错误路径中缺少的 page_pool_destroy（） 调用。（CVE-2026-31645）

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

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

  - nfcpn533在消耗字节之前分配 rx skb pn532_receive_buf() 向 serdev 核心报告已接受的字节数。当前代码将字节消耗至 recv_skb 中并且可能在分配新的接收缓冲区之前已将完整的帧移至 pn533_recv_frame()。如果 alloc_skb() 失败回调会返回 0即使其已消耗 字节并且会将 recv_skb 作为空用于下一个接收回调。这会破坏 receive_buf() 核算约定并且还可能导致在下一个 skb_put_u8() 中出现空取消引用。改为在消耗下一个字节之前延迟分配接收 skb。如果分配失败则返回已接受的字节数。 (CVE-2026-31660)

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

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

  - ALSActxfi将 PTP 限制为单页面 Commit 391e69143d0a 将 CT_PTP_NUM 从 1 增加到 4以支持 256 回放流但该卡未正确使用额外的页面。CT20K2 硬件已有多个 VMEM_PTPAL 寄存器但单独使用这些寄存器需要重构整个虚拟内存分配逻辑。 ct_vm_map() 始终使用 vm->ptp[0].area 中的 PTE而不管 CT_PTP_NUM。
    在 AMD64 系统上单个 PTP 涵盖 512 个 PTE (2M)。当聚合内存分配超过此限制时ct_vm_map() 会尝试访问超出分配的空间并造成页面错误BUG无法处理地址 ffffd4ae8a10a000 的页面错误 Oops: Oops: 0002 [#1] SMP PTI RIP: 0010 ct_vm_map+0x17c/0x280 [snd_ctxfi] Call Trace: atc_pcm_playback_prepare+0x225/0x3b0 ct_pcm_playback_prepare+0x38/0x60 snd_pcm_do_prepare+0x2f/0x50 snd_pcm_action_single+0x36/0x90 snd_pcm_action_nonatomic+0xbf/0xd0 snd_pcm_ioctl+0x28/0x40 __x64_sys_ioctl+0x97/0xe0 do_syscall_64+0x81/ 0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e 将 CT_PTP_NUM 恢复为 1。256 SRC_RESOURCE_NUM 和回放计数保持不变。 (CVE-2026-31602)

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

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

  - Authlib 是构建 OAuth 和 OpenID Connect 服务器的 Python 库。在 1.6.11之前的版本中authlib.integrations.starlette_client.OAuth 的缓存功能没有 CSRF 保护。此漏洞已在 1.6.11 中修复。(CVE-2026-41425)

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

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

  - drm/i915/gt：在推迟前检查set_default_submission（） 当i915驱动固件二进制文件不存在时，set_default_submission指针未被设置。这个指针在暂停时会被取消引用。在去引用前加个检查确认设置。[ 23.289926] PM：暂停进入（深度） [23.293558] 文件系统同步：0.000秒 [ 23.298010] 冻结用户空间进程 [ 23.302771] 冻结用户空间进程已完成（经过秒0.000） [ 23.309766] OOM 杀手被禁用。[23.313027] 冻结剩余可冻结任务 [ 23.318540] 冻结剩余可冻结任务完成（经过秒0.001） [ 23.342038] 序列 00:05： 禁用 [ 23.345719] 序列 00:02： 禁用 [ 00:0123.349342序列 ： 禁用 [ 23.353782] sd 0：0：0： [sda] 同步 SCSI 缓存 [ 23.358993] sd 1：0：0：0： [sdb] 同步 SCSI 缓存 [ 23.361635] ata1.00： 进入待机电源模式 [ 23.368863] ata2.00： 进入待机电源模式 [ 23.445187] BUG：内核 NULL 指针引用，地址：
    0000000000000000000 [ 23.452194] #PF：内核模式下的监督指令取指 [ 23.457896] #PF：
    error_code（0x0010） - 不存在页面 [ 23.463065] PGD 0 P4D 0 [ 23.465640] 哎呀：哎呀：0010 [#1] SMP NPP [ 23.469869] CPU： 8 UID： 0 PID： 211 通信： kworker/u48：18 污染： G S W 6.19.0-rc4-00020-gf0b9d8eb98df #10 抢占（自愿） [ 23.482512] 污染： [S]=CPU_OUT_OF_SPEC， [W]=WARN [ 23.496511] 工作队列：异步 async_run_entry_fn [ 23.501087] RIP： 0010：0x0 [ 23.503755] 代码：无法访问0xffffffffffffffd6的操作码字节。[ 23.510324] RSP：0018：ffffb4a60065fca8 EFLAGS：00010246 [23.515592] RAX：000000000000000000000 RBX：ffff9f428290e000 RCX：000000000000000f [ 23.522765] RDX：
    000000000000000 RSI：0000000000000282 RDI：ffff9f428290e000 [ 23.529937] RBP：ffff9f4282907070 R08：
    ffff9f4281130428 R09： 00000000ffffffff [ 23.537111] R10： 00000000000000000000 R11： 0000000000000001 R12：
    ffff9f42829070f8 [ 23.544284] R13： ffff9f4282906028 R14： ffff9f428290000 R15： ffff9f4282906b68 [23.551457] FS： 0000000000000000000（0000） GS：ffff9f466b2cf000（0000） knlGS：00000000000000000000000 [ 23.559588] CS：
    0010 DS： 0000 ES： 0000 CR0： 0000000080050033 [ 23.565365] CR2： ffffffd6 CR3： 000000031c230001 CR4：
    0000000000f70ef0 [ 23.572539] PKRU： 55555554 [ 23.575281] 呼叫追踪：[ 23.577770] <TASK> [ 23.579905] intel_engines_reset_default_submission+0x42/0x60 [ 23.585695] __intel_gt_unset_wedged+0x191/0x200 [23.590360] intel_gt_unset_wedged+0x20/0x40 [ 23.594675] gt_sanitize+0x15e/0x170 [ 23.598290] i915_gem_suspend_late+0x6b/0x180 [ 23.602692] i915_drm_suspend_late+0x35/0xf0 [ 23.607008] ？
    __pfx_pci_pm_suspend_late+0x10/0x10 [ 23.611843] dpm_run_callback+0x78/0x1c0 [ 23.615817] device_suspend_late+0xde/0x2e0 [ 23.620037] async_suspend_late+0x18/0x30 [ 23.624082] async_run_entry_fn+0x25/0xa0 [ 23.628129] process_one_work+0x15b/0x380 [ 23.632182] worker_thread+0x2a5/0x3c0 [ 23.635973] ？ __pfx_worker_thread+0x10/0x10 [ 23.640279] kthread+0xf6/0x1f0 [23.643464] ？ __pfx_kthread+0x10/0x10 [ 23.647263] __pfx_kthread+0x10/0x10 [ 23.651045] ret_from_fork+0x131/0x190 [ 23.654837] __pfx_kthread+0x10/0x10 [ 23.658634] ret_from_fork_asm+0x1a/0x30 [ 23.662597] </TASK>23.664826[ ] 模块链接于 [ 23.667914] CR2： 000000000000000000000 23.671271
    ------------[此处切]------------（摘自commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad）CVE-2026-31540 （）

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

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

  - rxrpc：修复 call->key 中的密钥引用计数泄漏 在 rxrpc_alloc_client_call（） 中创建客户端调用时，代码会获取对密钥的引用。此值永远不会清理，并且会在调用遭到破坏时泄露。通过释放 rxrpc_destroy_call（） 中的 call->key 修复此问题。修补程序之前，显示密钥引用计数器已提升：$ cat /proc/keys |grep afs@54321 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321：ka $ 修补程序之后，当代码退出时，无效的密钥会删除： $ cat /proc/keys |grep afs@54321 $ （CVE-2026-31639）

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

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

  - usb：gadget：f_phonet：修复 pn_rx_complete（） 中的 skb frags[] 溢出 broken/bored/mean USB 主机可通过发送不受限制的整页 OUT 传输序列，造成 Linux 小工具上的 skb_shared_info->frags[] 数组溢出，从而暴露 Phonet 函数。pn_rx_complete（） 仅在 req->actual < req->length 时才会最终完成 skb，其中 req->length 被小工具设置为 PAGE_SIZE。如果主机每次传输始终发送正好 PAGE_SIZE 字节，则 fp->rx.skb 永远不会被重置，每次完成都会通过 skb_add_rx_frag（） 添加另一个片段。一旦nr_frags超过 MAX_SKB_FRAGS（默认为 17），后续的 frag 存储将覆盖堆上 shinfo 附近的内存。达到 frag 限制时，删除 skb 并说明长度错误，从而与通过提交 f0813bcd2d9d 在 t7xx 中应用的补丁相匹配（net：wwan：t7xx：修复 RX 路径中潜在的 skb->frags 溢出）。（CVE-2026-31616）

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

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

  - stagingsm750fb修复 ps_to_hz() 中的除以零问题从 hw_sm750_crtc_set_mode() 调用 ps_to_hz()而不验证 pixclock 是否非零。通过 FBIOPUT_VSCREENINFO 传递的零 pixclock 会造成除以零。通过拒绝 lynxfb_ops_check_var() 中的零 pixclock 与其他帧缓冲区驱动程序保持一致(CVE-2026-31603)

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

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

  - 已修复 Linux 内核中的下列漏洞：vfio/xe: Reorganize the init to decouple migration from reset Attempting to issue reset on VF devices that don't support migration leads to the following: BUG: unable to handle page fault for address: 00000000000011f8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 7443 Comm: xe_sriov_flr Tainted: G S U 7.0.0-rc1-lgci-xe-xe-4588-cec43d5c2696af219-nodebug+ #1 PREEMPT(lazy) Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name:
    Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 RIP: 0010:xe_sriov_vfio_wait_flr_done+0xc/0x80 [xe] Code: ff c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 54 53 <83> bf f8 11 00 00 02 75 61 41 89 f4 85 f6 74 52 48 8b 47 08 48 89 RSP: 0018:ffffc9000f7c39b8 EFLAGS: 00010202 RAX:
    ffffffffa04d8660 RBX: ffff88813e3e4000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000f7c39c8 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000000 R12: ffff888101a48800 R13: ffff88813e3e4150 R14: ffff888130d0d008 R15: ffff88813e3e40d0 FS: 00007877d3d0d940(0000) GS:ffff88890b6d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000011f8 CR3: 000000015a762000 CR4: 0000000000f52ef0 PKRU: 55555554 Call Trace: <TASK> xe_vfio_pci_reset_done+0x49/0x120 [xe_vfio_pci] pci_dev_restore+0x3b/0x80 pci_reset_function+0x109/0x140 reset_store+0x5c/0xb0 dev_attr_store+0x17/0x40 sysfs_kf_write+0x72/0x90 kernfs_fop_write_iter+0x161/0x1f0 vfs_write+0x261/0x440 ksys_write+0x69/0xf0
    __x64_sys_write+0x19/0x30 x64_sys_call+0x259/0x26e0 do_syscall_64+0xcb/0x1500 ? __fput+0x1a2/0x2d0 ? fput_close_sync+0x3d/0xa0 ? __x64_sys_close+0x3e/0x90 ? x64_sys_call+0x1b7c/0x26e0 ? do_syscall_64+0x109/0x1500 ? __task_pid_nr_ns+0x68/0x100 ? __do_sys_getpid+0x1d/0x30 ? x64_sys_call+0x10b5/0x26e0 ? do_syscall_64+0x109/0x1500 ? putname+0x41/0x90 ? do_faccessat+0x1e8/0x300 ?
    __x64_sys_access+0x1c/0x30 ? x64_sys_call+0x1822/0x26e0 ? do_syscall_64+0x109/0x1500 ? tick_program_event+0x43/0xa0 ? hrtimer_interrupt+0x126/0x260 ? irqentry_exit+0xb2/0x710 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7877d5f1c5a4 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d a5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fff48e5f908 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007877d5f1c5a4 RDX:
    0000000000000001 RSI: 00007877d621b0c9 RDI: 0000000000000009 RBP: 0000000000000001 R08: 00005fb49113b010 R09: 0000000000000007 R10: 0000000000000000 R11: 0000000000000202 R12: 00007877d621b0c9 R13:
    0000000000000009 R14: 00007fff48e5fac0 R15: 00007fff48e5fac0 </TASK> This is caused by the fact that some of the xe_vfio_pci_core_device members needed for handling reset are only initialized as part of migration init. Fix the problem by reorganizing the code to decouple VF init from migration init. (CVE-2026-31601)

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

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

  - mm：直接调用 folio_unmap_invalidate（）中的 ->free_folio（） 。只有当我们对该映射有引用（或对该映射保持锁定）时，才能调用 filemap_free_folio（）。否则，我们已经把对应页从映射中移除了，所以它不再钉住映射，映射可以被移除，导致访问映射时出现免费使用后>a_ops。按照和__remove_mapping（）相同的模式，加载free_folio函数指针，然后再解除映射锁定。这样我们就能把filemap_free_folio（）做成静态，因为这是filemap.c之外唯一的调用者。（CVE-2026-31589）

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

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

  - fbdev： tdfxfb： 避免在FBIOPUT_VSCREENINFO上用零除法 类似于提交 19f953e74356（fbdev：
    fb_pm2fb：避免电位除以零的误差），我们还需要防止 udlfb 驱动发生同样的崩溃，因为它在除法时直接使用 pixclock，导致崩溃。（CVE-2026-31618）

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

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

  - mediahackrf进行修复以在 hackrf_probe() 中注册设备后不释放内存。在 hackrf 驱动程序中会发生以下争用条件`` CPU0 CPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev ....
    v4l2_device_register(); .... fd = sys_open(/path/to/dev); // open hackrf fd ....
    v4l2_device_unregister(); .... kfree(); // 释放 hackrf_dev .... sys_ioctl(fd, ...); v4l2_ioctl();
    video_is_registered() // UAF .... sys_close(fd); v4l2_release() // UAF hackrf_video_release() kfree();
    // DFB停用 V4L2 或视频设备时设备节点将被删除因此新的 open() 调用会遭到阻止。但是已打开的文件描述符以及任何飞行中的 I/O不会立即终止而是会终止。在删除最后一个引用并调用驱动程序的 release() 之前它们将保持有效。
    因此在 hackrf_probe() 注册 dev 之后释放错误路径上的设备内存将导致释放后使用漏洞争用因为那些已经打开的句柄尚未释放。并且由于 release() 也释放内存因此会发生释放后使用争用和双重释放漏洞。为防止发生此问题如果设备是通过 probe() 注册的则应将其修改为仅通过 release() 来释放内存而不是直接调用 kfree()。 (CVE-2026-31576)

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

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

  - net：usb：cdc-phonet：修复 rx_complete（） 中的 skb frags[] 溢出 自称是 CDC Phonet 调制解调器的恶意 USB 设备可通过发送不受限制的整页批量传输序列，使 skb_shared_info->frags[] 数组溢出。达到 frag 限制时，删除 skb 并增加长度误差。这与提交 f0813bcd2d9d 对 t7xx 驱动程序执行的相同修复（net：wwan：t7xx：修复 RX 路径中潜在的 skb->frags 溢出）进行了的修复。（CVE-2026-31623）

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

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

  - PostCSS 接受 CSS 文件并提供 API 通过将规则转换为抽象语法树来分析和修改其规则。字符串化 CSS AST 时 8.5.10 之前的版本不会转义“</style>”序列。当解析用户提交的 CSS 并重新字符串化以嵌入 HTML“<style>”标签时CSS 值中的“</style>”会中断样式上下文从而启用 XSS。版本 8.5.10 已修复该问题。(CVE-2026-41305)

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

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

  - fbdev： udlfb： 避免在FBIOPUT_VSCREENINFO上除以零 类似于提交 19f953e74356（fbdev： fb_pm2fb：
    避免电位除以零的误差），我们还需要防止 udlfb 驱动发生同样的崩溃，因为它在除法时直接使用 pixclock，导致崩溃。（CVE-2026-31605）

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

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

  - PCI端点pci-epf-vntb删除重复的资源拆卸 epf_ntb_epc_destroy() 会复制调用程序应在稍后执行的拆卸。这会在 .allow_link 失败或执行 .drop_link 时导致 oops。以下是前一种情况的 oops 示例无法处理虚拟地址 dead000000000108 上的内核分页请求 [...] [dead000000000108] 用户和内核地址范围之间的地址内部错误Oops: 0000000096000044 [#1] SMP [.. .] 调用跟踪
    pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlink_put,and drop. EPC 设备引用计数与 configfs EPC 群组生存期关联并且 .drop_link 路径中的 pci_epc_put() 就足够了。 (CVE-2026-31594)

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

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

  - net：altera-tse：修复 tse_start_xmit（） 中 DMA 映射错误中的 skb 泄漏 当 dma_map_single（） 在 tse_start_xmit（） 中失败时，函数返回 NETDEV_TX_OK 而不释放 skb。由于 NETDEV_TX_OK 告知堆栈数据包已被消耗，因此永远不会释放 skb，从而在每次 DMA 映射失败时泄漏内存。返回前添加 dev_kfree_skb_any（） 以正确释放 skb。（CVE-2026-31658）

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

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

  - bcache修复 cached_dev.sb_bio 的释放后使用和崩溃在我们的生产环境中我们收到了与 libceph 相关的多个崩溃报告引起了我们的注意`[ [6888366.280350] 调用跟踪[6888366.280452] blk_update_request+ 0x14e/0x370 [6888366.280561] blk_mq_end_request+0x1a/0x130 [6888366.280671] rbd_img_handle_request+0x1a0/0x1b0 [rbd] [6888366.280792] rbd_obj_handle_request+0x32/0x40 [rbd] [6888366.280903] __complete_request+0x22/0x130 [libceph] [libceph6888366.281032] ] ] osd_dispatch+0x15e/0xb40 [libceph] [6888366.281164] ? inet_recvmsg+0x5b/0xd0 [6888366.281272] ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph] [6888366.281405] ceph_con_process_message+0x79/0x140 [libceph] [6888366.281534] ceph_con_v1_try_read+0x5d7/0xf30 [libceph] [6888366.281661] ceph_con_workfn+0x329/0x680 [libceph] ` coredump 文件中发现 dc->sb_bio 的地址已被释放。我们知道 cached_dev 在停止时仅会释放。
    由于 sb_bio 是 struct cached_dev 的一部分而非每次都进行分配。如果设备在写入超级块时停止则 endio 将访问已释放的地址。此修补程序希望等待 sb_write 在 cached_dev_free 中完成。应该注意的是我们分析了问题的原因然后将所有详细信息告知 QWEN并采用了其所做的修改。 (CVE-2026-31580)

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

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

  - 固件：arm_scmi：修复通知错误路径上的NULL引用，自提交b5daf93b809d1以来（固件：
    arm_scmi：避免对不支持事件进行通知注册）指向辅助器的调用链
    __scmi_event_handler_get_ops期望在未能获得请求事件密钥的处理程序时返回ERR_PTR，而当前助手在找不到或创建程序时仍可返回NULL。当处理程序引用为NULL时，强制返回ERR_PTR值来解决。（CVE-2026-31544）

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

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

  - cangw修复 cgw_csum_crc8_rel() 中的 OOB 堆访问 cgw_csum_crc8_rel() 通过 calc_idx() int from = calc_idx(crc8->from_idx, cf->len); 正确计算边界安全索引int to = calc_idx(crc8->to_idx, cf->len); int res = calc_idx(crc8->result_idx, cf->len); if 从 < 0 || 到 < 0 || res < 0
    然而然后循环和结果写入会直接使用原始 s8 字段而非计算变量 for (i = crc8->from_idx; ...) /* BUG原始负索引 */ cf->data[crc8- >result_idx] = ...
    /* BUG原始负索引 */ 由于 64 字节 CAN FD 帧上的 from_idx = to_idx = result_idx = -64calc_idx(-64, 64) = 0所以防护通过但循环以 i = -64 迭代读取 cf->data[-64]而写入转到 cf->data[-64]。此写入可能比 canfd_frame 在堆上的开始前 56 (7.0-rc) 或 40 (<= 6.19) 字节结束。配套函数 cgw_csum_xor_rel() 始终正确使用“from”/“to”/“res”修复 cgw_csum_crc8_rel() 以匹配。已与 linux-7.0-rc2 上的 KASAN 确认缺陷KASAN
    cgw_csum_crc8_rel+0x515/0x5b0 在地址 ffff8880076619c8 执行的大小为 1 的读取中存在 slab 越界由任务 poc_cgw_oob/62 进行配置 can-gw crc8 校验和需要 CAP_NET_ADMIN。 (CVE-2026-31570)

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

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

  - i2c：designware：amdisp：修复 resume-probe 争用条件问题 已确定内核 v7.0 的提交 38fa29b01a6a 中的 resume-probe 争用条件（i2c：designware：合并 init 函数），但此问题从一开始就存在，但未被检测到。amdisp i2c 设备需要 ISP 处于开机状态才能成功探测。为了满足此要求，将此设备添加到 genpd 以使用运行时 PM 来控制 ISP 功率。在 i2c_dw_probe（） 之前调用的 pm_runtime_get_sync（） 会触发 PM 恢复，从而在探测完成之前打开 ISP 并调用 amdisp i2c 运行时恢复，从而导致此争用条件和 v7.0 中的空取消引用问题 通过在探测期间直接使用 genpd API 来修复此争用条件： - 在探测之前调用 dev_pm_genpd_resume（） 以打开 ISP 的电源 - 在探测后调用 dev_pm_genpd_suspend（） 以关闭 ISP 的电源 -通过 pm_runtime_set_suspended（） 将设备设为暂停状态 - 仅在设备完全初始化后启用运行时 PM （CVE-2026-31572）

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

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

  - futex清除 futex_lock_pi() 中已触发的模糊/强调 futex 重试路径中的过时退出指针
    警告kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80 CPU#11futex_lock_pi_s/524 当 futex_lock_pi_atomic() 发现所有者正在退出时会返回 -EBUSY 并将引用计数的任务指针存储在“exiting”中。在 wait_for_owner_exiting() 消耗该引用后本地指针绝不会重置为 nil。重试时如果 futex_lock_pi_atomic() 返回其他错误则虚假的指针将传递至 wait_for_owner_exiting()。CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // 获取 PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // 观察到 EXITING *exiting = owner; // 采用 ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drop ref // exiting still Points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // // 更改 // 任何值 return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting) 通过在重试时重置基本上使其与 requeue_pi 对齐来修复此问题。 (CVE-2026-31555)

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

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

  - ERB 是适用于 Ruby 的模板系统。Ruby 2.7.0 在 rubygems.org 上发布 ERB 2.2.0 之前在通过“Marshal”重建 ERB 对象时在“ERB#result”和“ERB#run”中引入了“@_init”实例变量保护以阻止代码执行。 load`反序列化。但是，也未为也通过“eval()”评估“@src”的其他三个公共方法提供相同的保护：“ERB#def_method”、“ERB#def_module”和“ERB#def_class”。能够对加载了“erb”的 Ruby 应用程序中不受信任的数据触发“Marshal.load”的攻击者可将“ERB#def_module”零参数默认参数用作代码执行接收器从而绕过“@_init”完全保护。ERB 4.0.3.1、 4.0.4.1、 6.0.1.1和 6.0.4 修补了此问题。 (CVE-2026-41316)

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

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

  - s390/mm：为捐赠的内存添加缺少的安全存储访问修复 在某些特殊情况下，未设置 PG_arch_1 位的页面的内核上下文中会发生安全存储访问异常。该位用于非导出的客户机安全存储（内存）设置，但在捐赠给 Ultravisor 的存储中不存在该位，因为内核不允许导出捐赠的页面。在此修补程序之前，我们将尝试通过调用 arch_make_folio_accessible（） 来导出页面，它会立即返回，因为缺少 arch 位，表示页面已导出并且无需进一步操作。这会导致永远无法解决的安全存储访问异常循环。通过此修补程序，我们会无条件地尝试导出，如果失败，我们会进行修复。（CVE-2026-31568）

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

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

  - 已修复 Linux 内核中的下列漏洞：smb: client: make use of smbdirect_socket.recv_io.credits.available The logic off managing recv credits by counting posted recv_io and granted credits is racy. That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist. So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer. (CVE-2026-31535)

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

ID	名称	严重性
310314	Linux Distros 未修补的漏洞：CVE-2026-31578	high
310313	Linux Distros 未修补的漏洞：CVE-2026-31598	high
310312	Linux Distros 未修补的漏洞：CVE-2026-31574	medium
310311	Linux Distros 未修补的漏洞：CVE-2026-31613	high
310310	Linux Distros 未修补的漏洞：CVE-2026-31595	medium
310309	Linux Distros 未修补的漏洞：CVE-2026-31657	critical
310308	Linux Distros 未修补的漏洞：CVE-2026-31584	high
310307	Linux Distros 未修补的漏洞：CVE-2026-31621	medium
310306	Linux Distros 未修补的漏洞：CVE-2026-31596	medium
310305	Linux Distros 未修补的漏洞：CVE-2026-31606	medium
310304	Linux Distros 未修补的漏洞：CVE-2026-31629	high
310303	Linux Distros 未修补的漏洞：CVE-2026-31659	critical
310302	Linux Distros 未修补的漏洞：CVE-2026-31610	medium
310301	Linux Distros 未修补的漏洞：CVE-2026-31651	medium
310300	Linux Distros 未修补的漏洞：CVE-2026-31615	medium
310299	Linux Distros 未修补的漏洞：CVE-2026-31536	critical
310298	Linux Distros 未修补的漏洞：CVE-2026-31587	high
310297	Linux Distros 未修补的漏洞：CVE-2026-31577	medium
310296	Linux Distros 未修补的漏洞：CVE-2026-31611	high
310295	Linux Distros 未修补的漏洞：CVE-2026-31612	high
310294	Linux Distros 未修补的漏洞：CVE-2026-31626	high
310293	Linux Distros 未修补的漏洞：CVE-2026-41476	high
310292	Linux Distros 未修补的漏洞：CVE-2026-40254	medium
310291	Linux Distros 未修补的漏洞：CVE-2026-31646	medium
310290	Linux Distros 未修补的漏洞：CVE-2026-31608	critical
310289	Linux Distros 未修补的漏洞：CVE-2026-31645	medium
310288	Linux Distros 未修补的漏洞：CVE-2026-31660	medium
310287	Linux Distros 未修补的漏洞：CVE-2026-31602	high
310286	Linux Distros 未修补的漏洞：CVE-2026-41425	medium
310285	Linux Distros 未修补的漏洞：CVE-2026-31540	medium
310284	Linux Distros 未修补的漏洞：CVE-2026-31639	medium
310283	Linux Distros 未修补的漏洞：CVE-2026-31616	medium
310282	Linux Distros 未修补的漏洞：CVE-2026-31603	medium
310281	Linux Distros 未修补的漏洞：CVE-2026-31601	medium
310280	Linux Distros 未修补的漏洞：CVE-2026-31589	critical
310279	Linux Distros 未修补的漏洞：CVE-2026-31618	medium
310278	Linux Distros 未修补的漏洞：CVE-2026-31576	high
310277	Linux Distros 未修补的漏洞：CVE-2026-31623	medium
310276	Linux Distros 未修补的漏洞：CVE-2026-41305	medium
310275	Linux Distros 未修补的漏洞：CVE-2026-31605	medium
310274	Linux Distros 未修补的漏洞：CVE-2026-31594	medium
310273	Linux Distros 未修补的漏洞：CVE-2026-31658	medium
310272	Linux Distros 未修补的漏洞：CVE-2026-31580	high
310180	Linux Distros 未修补的漏洞：CVE-2026-31544	medium
310179	Linux Distros 未修补的漏洞：CVE-2026-31570	high
310178	Linux Distros 未修补的漏洞：CVE-2026-31572	medium
310177	Linux Distros 未修补的漏洞：CVE-2026-31555	medium
310176	Linux Distros 未修补的漏洞：CVE-2026-41316	high
310175	Linux Distros 未修补的漏洞：CVE-2026-31568	high
310174	Linux Distros 未修补的漏洞：CVE-2026-31535	medium

检测

Nessus 的 Misc. 系列

high

high

medium

high

medium

critical

high

medium

medium

medium

high

critical

medium

medium

medium

critical

high

medium

high

high

high

high

medium

medium

critical

medium

medium

high

medium

medium

medium

medium

medium

medium

critical

medium

high

medium

medium

medium

medium

medium

high

medium

high

medium

medium

high

high

medium