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

  - ocfs2：修复缓冲区已满时的 listxattr 处理 [缺陷] 如果 OCFS2 inode 同时具有内联和基于区块的 xattrs，则当内联名称恰好消耗缓冲区时，listxattr（） 可返回大于调用程序缓冲区的大小。mm/usercopy.c：102！ 处的内核缺陷哎呀：无效操作码：0000 [#1] SMP KASAN NOPTI RIP：
    0010：usercopy_abort+0xb7/0xd0 mm/usercopy.c：102 调用跟踪：__check_heap_object+0xe3/0x120 mm/slub.c：8243 check_heap_object mm/usercopy.c：196 [内联] __check_object_size mm/usercopy.c：250 [内联]
    __check_object_size+0x5c5/0x780 mm/usercopy.c：215 check_object_size include/linux/ucopysize.h：22 [内联] check_copy_size include/linux/ucopysize.h：59 [内联] copy_to_user include/linux/uaccess.h：219 [内联] listxattr+0xb0/0x170 fs/xattr.c：926 filename_listxattr fs/xattr.c：958 [内联] path_listxattrat+0x137/0x320 fs/xattr.c：988 __do_sys_listxattr fs/xattr.c：1001 [内联] __se_sys_listxattr fs/xattr.c：998 [内联] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c：998 ... [原因]提交 936b8834366e（ocfs2：重构 xattr 列表并删除 ocfs2_xattr_handler（）.） 用 ocfs2_xattr_list_entry（） 替换了旧的每个处理程序列表统计，但它仍然使用 size == 0 来检测探测模式。一旦 ocfs2_listxattr（） 完成 inline-xattr 传递，该假设就不再成立。如果内联名称恰好填充调用程序缓冲区，则 block-xattr 传递会使用非空缓冲区运行，剩余大小为零。然后，ocfs2_xattr_list_entry（） 跳过边界检查，继续计数块名称，并返回大于提供的缓冲区的正大小。[修复]通过测试目标缓冲区指针是否为空而非剩余大小是否为零，来检测探测模式。这会恢复重构前的行为，并符合 OCFS2 getxattr 帮助程序。一旦剩余缓冲区达到零并且还剩下更多名称，block-xattr 传递现在会返回 -ERANGE，而不是报告大于分配的列表缓冲区的大小。（CVE-2026-53041）

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

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

  - netfilter：nat：使用 kfree_rcu 释放 ops Florian Westphal 说：从历史上看，这不是问题，即使对于普通的 base hook 也是如此：数据路径不使用用于注册回调的原始nf_hook_ops。但是，在 v5.14 中，我添加了从用户空间转储活动 netfilter 挂钩的功能。
    此代码将回窥探数据路径使用的指针数组 blob 末尾可用的nf_hook_ops。nat 挂钩很特殊，因为它们是从中央 nat 调度程序挂钩间接调用的。不过，它们目前对 nfnl 挂钩转储子系统不可见。但是，一旦情况发生变化，自然运营结构也必须推迟。更新 nf_nat_register_fn（） 以处理错误路径中挂钩的部分暴露，这对nfnetlink_hook来说也可能是个问题。（CVE-2026-53000）

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

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

  - ASoC：sti：使用托管的regmap_field分配 玩家初始化时分配的 regmap_field 对象永远不会释放，而且如果删除驱动程序，可能会泄漏资源。切换到 devm_regmap_field_alloc（） 可自动限制分配的生命周期，即设备的生命周期。（CVE-2026-53065）

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

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

  - ImageMagick 之前 7.1.2-15 在多个编码器中包含一个内存泄漏漏洞，这些编码器会在分配的对象未正确释放的情况下写入原始像素数据。攻击者可通过处理特别构建的图像触发此泄漏，从而造成内存耗尽和拒绝服务。(CVE-2026-56368)

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

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

  - netfilter：nfnetlink_osf：修复选项匹配时的越界读取 在 nf_osf_match（） 中，会初始化一次 nf_osf_hdr_ctx 结构，并通过引用传递给每个检查指纹的 nf_osf_match_one（）。
    在 TCP 选项解析期间，nf_osf_match_one（） 推进共享的 ctx->optp 指针。如果指纹完全匹配，该函数将提早返回，而不会将 ctx->optp 恢复到其初始状态。如果用户已配置NF_OSF_LOGLEVEL_ALL，则循环将继续到下一个指纹。但是，由于未恢复 ctx->optp，因此对 nf_osf_match_one（） 的下一次调用会从选项缓冲区末尾开始解析。这会导致后续匹配读取垃圾数据并立即失败，使其无法记录多个匹配或记录不正确的匹配。不要使用共享的 ctx->optp 指针，而是将上下文作为常量指针传递，并使用本地指针 （optp） 进行 TCP 选项遍历。从调用者的角度来看，这会使 nf_osf_match_one（） 严格无状态，从而确保每项指纹检查从正确的选项偏移量开始。（CVE-2026-52999）

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

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

  - sched/psi：修复文件释放和压力写入之间的争用 压力写入和 cgroup 文件释放之间存在一个涉及 struct kernfs_open_file 的 priv 成员的潜在争用条件，这会触发 [1] 中报告的 UAF。考虑以下涉及在两个独立 CPU 上执行的场景： CPU0 CPU1 ==== ==== vfs_rmdir（） kernfs_iop_rmdir（） cgroup_rmdir（） cgroup_kn_lock_live（） cgroup_destroy_locked（） cgroup_addrm_files（） cgroup_rm_file（） kernfs_remove_by_name（） kernfs_remove_by_name_ns（） vfs_write（） __kernfs_remove（） new_sync_write（） kernfs_drain（） kernfs_fop_write_iter（） kernfs_drain_open_files（） cgroup_file_write（） kernfs_release_file（） pressure_write（） cgroup_file_release（） ctx = of->priv;kfree（ctx）;of->priv = NULL;cgroup_kn_unlock（） cgroup_kn_lock_live（） cgroup_get（cgrp） cgroup_kn_unlock（） if （ctx->psi.trigger） // 此处，触发 ctx 的 UAF，即 of->priv cgroup_rmdir（） 受 cgroup_mutex 保护，同时保护在 cgroup_file_release（） 中执行的 of->priv 的内存解除分配。但是，在 pressure_write（） 中执行的涉及 of->priv 的操作并不完全在 cgroup_mutex 的保护范围内。
    因此，如果 pressure_write（） 中的代码（尤其是处理 ctx 变量的区段）在 cgroup_file_release（） 完成后执行，则会触发涉及 of->priv 的 UAF 漏洞。因此，可以通过将 pressure_write（） 中的cgroup_mutex锁定范围扩展为包含涉及 of->priv 的所有代码路径来解决该问题，从而正确同步 cgroup_file_release（） 和 pressure_write（） 之间发生的争用条件。并且，如果在执行压力写入操作时能够成功获取实时 kn 锁定，则表示 cgroup 删除进程尚未达到其最终阶段;因此，open_file内的 priv 指针不能为空。因此，必须将检索 ctx 值的操作移至成功取得实时 kn 锁定 *之后*的某个点。在另一种情况下，特别是在输入 cgroup_kn_lock_live（） 之后但获取cgroup_mutex之前，存在不同类的争用条件：CPU0：写入 memory.pressure CPU1：写入 cgroup.pressure=0 =========================== ============================= kernfs_fop_write_iter（） kernfs_get_active_of（of） pressure_write（） cgroup_kn_lock_live（memory.pressure） cgroup_tryget（cgrp） kernfs_break_active_protection（kn） ...blocks on cgroup_mutex cgroup_pressure_write（） cgroup_kn_lock_live（cgroup.pressure） cgroup_file_show（memory.pressure， false） kernfs_show（false） kernfs_drain_open_files（） cgroup_file_release（of） kfree（ctx） of->priv = NULL cgroup_kn_unlock（） ...
    获取 cgroup_mutex ctx = of->priv;现在可能为空 if （ctx->psi.trigger） // 空取消引用 因此，存在 of->priv 为空的可能性，压力写入需要对此进行检查。
    现在cgroup_mutex的范围已扩大，不再需要原来的显式cgroup_get/put 操作，这是因为获取/释放实时 kn 锁定本质上会执行 cgroup get/put 操作。[1] 缺陷：KASAN：pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c：4011 中的释放后使用 slab 调用跟踪：pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c：4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c：43 ---truncated--- （CVE-2026-52991）

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

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

  - f2fs：避免在垃圾回收期间读取已更新的页面 我们在模糊测试期间发现以下问题：
    page：refcount：3 mapcount：0 mapping：00000000b6e89c65 index：0x18b2dc pfn：0x161ba9 memcg：f8ffff800e269c00 aops：f2fs_meta_aops ino：2 flags：
    0x52880000000080a9（locked|waiters|uptodate|lru|private|zone=1|kasantag=0x4a） raw： 52880000000080a9 fffffffec6e17588 fffffffec0ccc088 a7ffff8067063618 raw： 0000 0000000000000009 000003ffffffff f8ffff800e269c00 页面转储原因： VM_BUG_ON_FOLIO（folio_test_uptodate（folio）） page_owner 跟踪分配的页面 post_alloc_hook+0x58c/0x5ec prep_new_page+0x34/0x284 get_page_from_freelist+0x2dcc/0x2e8c __alloc_pages_noprof+0x280/0x76c __folio_alloc_noprof+0x18/0xac
    __filemap_get_folio+0x6bc/0xdc4 pagecache_get_page+0x3c/0x104 do_garbage_collect+0x5c78/0x77a4 f2fs_gc+0xd74/0x25f0 gc_thread_func+0xb28/0x2930 kthread+0x464/0x5d8 ret_from_fork+0x10/0x20 ------------[在此处剪切]------------mm/filemap.c：1563！folio_end_read+0x140/0x168 f2fs_finish_read_bio+0x5c4/0xb80 f2fs_read_end_io+0x64c/0x708 bio_endio+0x85c/0x8c0 blk_update_request+0x690/0x127c scsi_end_request+0x9c/0xb8c scsi_io_completion+0xf0/0x250 scsi_finish_command+0x430/0x45c scsi_complete+0x178/0x6d4 blk_mq_complete_request+0xcc/0x104 scsi_done_internal+0x214/0x454 scsi_done+0x24/0x34，类似于 syzbot 报告的问题：
    https://syzkaller.appspot.com/bug?extid=3686758660f980b402dc 此情况与提交 9bf1a3f 中的描述一致（f2fs：避免 GC 导致加密文件损坏）：通过move_data_block将页面 1 从 blkaddr A 移动到 blkaddr B，写入后将其标记为最新。然后，将页面 1 从 blkaddr B 移动到 blkaddr C，VM_BUG_ON_FOLIO在 ra_data_block 发起的 endio 中触发。无需从 blkaddr B 再次读取第 1 页，因为它已更新。因此，避免在此情况下启动 I/O。（CVE-2026-53018）

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

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

  - wifi：mt76：mt7921：修复 mt7921_roc_abort_sync roc_abort_sync（） 中可能发生的死锁，roc_work（） 可以与 （） 死锁。roc_work（） 保留 dev->mt76.mutex，而 cancel_work_sync（） 等待 roc_work（） 完成。如果调用方已拥有相同的互斥体，则双方都会阻塞，并且不可能有任何进展。当 mt76_sta_state（） -> mt76_sta_remove（） -> mt7921_mac_sta_remove（） -> mt7921_roc_abort_sync（） 调用 cancel_work_sync（） 而 roc_work（） 仍在运行并保留 dev->mt76.mutex 时，在删除工作站期间会发生此死锁。这可避免互斥体死锁，并保留恰好一次的工作所有权。
    (CVE-2026-53101)

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

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

  - powerpc/pgtable-frag：修复pte_frag_destroy powerpc 使用pt_frag_refcount作为引用计数器来跟踪其 pte 和 pmd 页表片段时的错误页面状态。对于 PTE 表，在 64K 页面大小的哈希的情况下，我们在一个 64K 页面中有 16 个 4K 大小的片段。修补程序系列 [1] mm：由 RCU 释放撤回的页表 为 shmem 范围内的 madvise MADV_COLLAPSE调用 retract_page_tables（） 时，释放 pte_free_defer（） 以延迟 PTE 表的释放。[1]:
    https://lore.kernel.org/all/7cd843a9-aa80-14f-5eb2-33427363c20@google.com/ pte_free_defer（） 在相应片段的 folio 上设置活动标记并调用 pte_fragment_free（），从而减少pt_frag_refcount。当pt_frag_refcount达到 0（没有活动片段使用作品集）时，它会检查是否设置了作品集活动标记，如果设置了，它会调用 call_rcu 来释放作品集，如果活动标记未设置，则调用 pte_free_now（）。现在，这在极端情况下可导致以下问题...[ 265.351553][ T183] BUG： 进程 a.out pfn：20d62 中的错误页面状态 [ 265.353555][ T183] page： refcount：0 mapcount：0 mapping：000000000000000 index：0x0 pfn：0x20d62 [ 265.355457][ T183] flags：
    0x3ffff800000100（active|node=0|zone=0|lastcpupid=0x7ffff）[ 265.358719][ T183] raw： 003ffff8000000100 00000000000000 5deadbeef0000122 0000000000000000 [ 265.360177][ T183] raw： 000000000000000000 c00000000119caf58 000000000ffffffff 000000000000000000 [ 265.361438][ T183] 页面转储，因为：
    PAGE_FLAGS_CHECK_AT_FREE flag（s） set [ 265.362572][ T183] 模块链接于： [ 265.364622][ T183] CPU： 0 UID： 0 PID： 183 Comm： a.out Not tainted 6.18.0-rc3-00141-g1ddeaaace7ff-dirty #53 VOLUNTARY [ 265.364785][T183] 硬件名称： IBM pSeries（由 qemu 模拟）（ POWER10 架构） 0x801200 0xf000006 of：SLOF，git-ee03ae pSeries [ 265.364908][ T183] 调用跟踪： [ 265.364955][ T183] [c0000000011e6f7c0] [c000000001cfaa18] dump_stack_lvl+0x130/0x148（不可靠） [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] bad_page+0xb4/0x1c8 [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020]
    __free_frozen_pages+0x838/0xd08 [ 265.365554][ T183] [c0000000011e6f980] [c0000000000a70ac] pte_frag_destroy+0x298/0x310 [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] arch_exit_mmap+0x34/0x218 [ 265.365912][ T183] [c000000011e） 6fa80] [c000000000751698] exit_mmap+0xb8/0x820 [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] __mmput+0x98/0x300 [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] do_exit+0x470/0x1508 [ 265.366421][ T183] [c000000011e6fd70] [c00000000001c95e4] do_group_exit+0x88/0x148 [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pid_child_should_wake+0x0/0x178 [ 265.366780][ T183] [c000000011e6f] df0] [c00000000003a270] system_call_exception+0x1b0/0x4e0 [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec 当从 do_exit（） 路径并行释放此类作品集时（设置活动标记）会发生错误页面状态错误。当从此作品集分配 PTE 片段时可能会发生这种情况，但当所有片段都得到释放后，pte_frag_refcount仍有一些未使用的片段。现在，如果此进程退出，其中包含缓存pte_frag mm->context 中的此类作品集，则在 pte_frag_destroy（） 期间，我们只需调用 pagetable_dtor（） 和 pagetable_free（），这意味着它不会清除活动标记。这可导致上述缺陷。由于我们无论如何都在 do_exit（） 路径中，那么如果 refcount 为 0，那么我想在调用 pagetable_dtor（） &; pagetable_free（） 之前简单地清除 folio 活动标记应该没问题。（CVE-2026-53109）

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

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

  - net：airoha：修复 TX 路径中的 BQL 不平衡 修复 airoha_dev_xmit（） 中可能存在的 BQL 不平衡，其中传输数据包只考虑AIROHA_NUM_TX_RING netdev TX 队列。队列索引的计算公式为：qid = skb_get_queue_mapping（skb） % ARRAY_SIZE（qdma->q_tx） txq = netdev_get_tx_queue（dev， qid）;但是，airoha_qdma_tx_napi_poll（） 帐户跨所有 netdev TX 队列 （num_tx_queues），导致 BQL 核算不一致。还会重置 ndo_stop 回调中的所有 netdev TX 队列。（CVE-2026-52983）

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

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

  - Faraday 是 HTTP 客户端库抽象层，提供多个适配器的通用接口。
    从 1.0.0 until 1.10.6 和 2.14.3， Faraday：：NestedParamsEncoder（Faraday 中的默认嵌套查询参数编码器/解码器）解码嵌套查询字符串，而不强制使用最大嵌套深度。特制的查询字符串导致 Faraday 构建深度嵌套的 Ruby 哈希结构。然后，内部反哈希例程以递归方式遍历此攻击者控制的结构，没有深度限制。在足够深处，Ruby 会引发未捕获的 SystemStackError（堆栈级别太深），从而导致调用线程或工作进程崩溃。这可在将攻击者控制的查询字符串传递至 Faraday 的嵌套查询解析或 URL 构建路径的应用程序中导致拒绝服务。此漏洞在 1.10.6 和 2.14.3中修复。
    (CVE-2026-54297)

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

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

  - libceph：修复 decode_choose_args（） 中潜在的 null-ptr-deref 类型 CEPH_MSG_OSD_MAP 的消息包含 OSD 映射，其本身也包含 CRUSH 映射。在 crush_decode（） 中解码此 CRUSH 映射时，会解码max_buckets 个 CRUSH 存储段的数组，其中某些索引可能不引用实际的存储段，因此设置为 NULL。接收到的 CRUSH 映射可选择包含在 decode_choose_args（） 中解码的choose_args。解码crush_choose_arg_map时，系统会解码一系列针对不同存储桶的choose_args，并从传入的消息中读取bucket_index。只检查存储桶索引是否超过 max_buckets，而不能检查它是否不指向具有 NULL 存储桶的索引。如果（可能损坏的）消息包含包含此类bucket_index的crush_choose_arg_map，则在尝试访问具有给定索引的存储段时，在后续处理中可能发生空指针取消引用。此修补程序通过扩展受影响的检查来修复此问题。现在，只会尝试访问非 NULL 的存储段。（CVE-2026-52957）

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

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

  - fs/mbcache：在破坏缓存之前取消压缩工作 mb_cache_destroy（） 调用 shrinker_free（） 然后释放所有缓存条目和缓存本身，但它不会首先取消待定的 c_shrink_work 工作项。如果 mb_cache_entry_create（） 通过 schedule_work（） 计划c_shrink_work，而运行 mb_cache_destroy（） 时工作项仍为待定或运行，则 mb_cache_shrink_worker（） 将在其内存释放后访问缓存，从而造成释放后使用。只有能够触发最后放置挂载的 ext2/ext4/ocfs2 文件系统的特权用户（根或CAP_SYS_ADMIN）才能访问此漏洞。在调用 shrinker_free（） 之前，使用 cancel_work_sync（） 取消工作项，确保工作线程已完成并且不会在缓存拆散之前重新计划。（CVE-2026-53129）

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

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

  - wifi：ath11k：修复信标模板设置中的内存泄漏 函数 ath11k_mac_setup_bcn_tmpl_ema（） 和 ath11k_mac_setup_bcn_tmpl_mbssid（） 函数为信标模板分配内存，但在参数设置返回错误时无法释放内存。由于信标模板必须在正常执行期间释放，因此还必须在错误处理路径中释放信标模板，以防止内存泄漏。通过使用统一的退出路径并在各自的错误路径中进行适当的清理来修复此问题。仅经过编译测试。使用原型静态分析工具和代码审查时发现的问题。（CVE-2026-53113）

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

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

  - 总线：fsl-mc：使用通用 driver_override 基础架构 通过 __driver_attach（） 探测驱动程序时，会在未保留设备锁的情况下调用总线的 match（） 回调，因此可在未保留设备锁的情况下访问driver_override字段，这可导致 UAF。通过使用负责内部适当锁定的驱动程序核心driver_override基础架构来修复此问题。请注意，在未保留设备锁定的情况下，从 __driver_attach（） 调用 match（） 是有意为之。[1] （CVE-2026-53115）

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

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

  - concurrent-ruby 是 Ruby 的现代并发工具。在 1.3.7 之前，Concurrent：：ReadWriteLock#release_write_lock 不会验证调用线程是否已获得写入锁。对锁定对象具有访问权限的任何线程都可以释放另一个线程持有的活动写入锁。然后，第二个写入器可以在第一个写入器仍在运行时进入其关键部分。
    Concurrent：：ReadWriteLock#release_read_lock 还会递减共享计数器，即使未保留读取锁定。在新锁定时调用它会将计数器从 0 更改为 -1，之后正常读取采集会引发 Concurrent：：ResourceLimitError。这是公共 Concurrent：：ReadWriteLock API 中的同步正确性问题。此漏洞已在 1.3.7 中修复。(CVE-2026-54906)

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

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

  - bpf：修复已卸载的 map/prog 信息填充中的释放后使用 当查询已卸载 BPF 映射或程序的信息时，bpf_map_offload_info_fill_ns（） 和 bpf_prog_offload_info_fill_ns（） 通过 get_net（dev_net（offmap->netdev）） 获取网络命名空间。但是，相关的 netdev 的 netns 在 netns 析构期间可能会因拆卸而争用。如果 netns refcount 已经达到 0，get_net（） 会在 0 上执行refcount_t递增，触发：refcount_t：在 0 上加法;释放后使用。尽管 rtnl_lock 和 bpf_devs_lock 确保 netdev 指针保持有效，但无法阻止 netns refcount 达到零。使用 maybe_get_net（） 而不是 get_net（） 来修复此问题。maybe_get_net（） 使用 refcount_inc_not_zero（） 并在 refcount 已经为零时返回 NULL，这导致 ns_get_path_cb（） 失败，并且调用程序返回 -ENOENT -- 这是销毁 netns 时的正确行为。
    (CVE-2026-53089)

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

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

  - concurrent-ruby 是 Ruby 的现代并发工具。在低于 1.3.7的 之前，Concurrent：：ReentrantReadWriteLock 可在一个线程获取读取锁定 32,768 次后错误地授予写锁定。该锁以一个整数形式存储线程的本地读取和写入保持计数。低 15 位用于读取保持计数，第 15 位用作WRITE_LOCK_HELD。在 32,768 次可重入读取采集后，本地读取计数交叉到写锁定位。然后，try_write_lock 将线程视为已经持有写入锁定，并在不设置全局 RUNNING_WRITER 位的情况下返回 true。这破坏了核心互斥保证：调用程序被告知其具有写入锁定，但其他线程仍可同时持有或获取读取锁定。此漏洞已在 1.3.7 中修复。(CVE-2026-54905)

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

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

  - md：修复 array_state=clear sysfs 死锁 将 clear 写入 array_state 时，md_attr_store（） 会中断 sysfs 主动保护，因此数组可从其自己的 sysfs 存储方法中删除自身。但 md_attr_store（） 目前会在调用 sysfs_unbreak_active_protection（） 之前终止 mddev 引用。一旦 do_md_stop（...， 0） 使 mddev 符合延迟删除的条件，sysfs_break_active_protection（） 获取的临时 kobject 引用将成为保护 md kobject 的最后一个 kobject 引用。这可让 sysfs_unbreak_active_protection（） 从当前 sysfs 写入器环境中删除最后一个 kobject 引用。然后，当当前 sysfs 节点仍在展开时，kobject 拆卸递归至 KernFS 删除，并且 lockdep 报告调用链中具有 kernfs_drain（） 的 kn->active 上的递归锁定。
    现有层级的复制程序：1. 创建并激活 md0 线性数组：mknod /dev/md0 b 9 0 echo none > /sys/block/md0/md/metadata_version echo linear > /sys/block/md0/md/level echo 1 > /sys/block/md0/md/raid_disks echo $(cat /sys/class/block/sdb/dev) > /sys/block/md0/md/new_dev echo $(($(cat /sys/class/block/sdb/size) / 2）） > \ /sys/block/md0/md/dev-sdb/size echo 0 > /sys/block/md0/md/dev-sdb/slot echo active > /sys/block/md0/md/array_state 2.短暂等待数组稳定，然后将其清除：sleep 2 echo clear > /sys/block/md0/md/array_state 警告如下所示：
    警告：检测到可能的递归锁定 bash/588 尝试获取 lock： （kn->active#65） at
    __kernfs_remove+0x157/0x1d0 但任务已在 sysfs_unbreak_active_protection+0x1f/0x40 保持锁定： （kn->active#65） ... 调用跟踪：kernfs_drain __kernfs_remove kernfs_remove_by_name_ns sysfs_remove_group sysfs_remove_groups __kobject_del kobject_put md_attr_store kernfs_fop_write_iter vfs_write ksys_write 在 mddev_put（） 之前恢复主动保护，以便在 mddev 仍处于活动状态时删除额外的 sysfs kobject 引用。然后，实际的 md kobject 删除将被推迟到 sysfs 写入路径完全返回之后。（CVE-2026-53125）

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

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

  - libceph：修复 __ceph_x_decrypt（） 中潜在的越界访问 在 __ceph_x_decrypt（） 中，缓冲区 p 的一部分会被解释为 ceph_x_encrypt_header，并可访问此结构的 magic 字段。此情况发生时无法保证缓冲区大小足以容纳此结构。函数参数 ciphertext_len 表示要解密的密文的长度，保证至多为分配的缓冲区 p 的剩余大小。但是，此值不一定大于 sizeof（ceph_x_encrypt_header）。例如，FRAME_TAG_AUTH_REPLY_MORE类型的消息帧，其长度刚好足以将密文保留在其结尾，ciphertext_len为 8 或更小，可在访问 hdr->magic 时触发越界内存访问。此修补程序通过添加检查来修复此问题，以确保缓冲区中解密的明文大小足以至少代表ceph_x_encrypt_header。
    (CVE-2026-52956)

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

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

  - sctp：调用 udp_tunnel_xmit_skb（） 之前禁用 BH udp_tunnel_xmit_skb（） / udp_tunnel6_xmit_skb（） 预期在禁用 BH 的情况下运行。提交 6f1a9140ecda（向隧道 xmit 函数添加 xmit 递归限制）后，路径上：udp（6）_tunnel_xmit_skb（） -> ip（6）tunnel_xmit（） dev_xmit_recursion_inc（）/dec（） 必须在相同 CPU 上保持平衡。如果没有 local_bh_disable（），上下文可能会在 CPU 之间移动，这可中断 inc/dec 配对。这可能导致不正确的递归级别检测并造成数据包在 ip（6）_tunnel_xmit（） 或 __dev_queue_xmit（） 中被丢弃。通过同时禁用围绕 IPv4 和 IPv6 SCTP UDP xmit 路径的 BH 来修复此问题。在我的测试中，在通过 UDP 启用 SCTP 后：# ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - 没有此修补程序： # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec 发送方 [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec 接收方 - 有了此修补程序： # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 秒 3.14 GBytes 2.69 Gbits/sec 发送方 [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec 接收器 （CVE-2026-53070）

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

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

  - wifi：libertas：不终止中断上下文中的 URB 通过调用 usb_kill_urb（）/usb_kill_anchored_urbs（） 来强制执行 TX 路径的序列化，以防止在之前的 URB 完成之前进行传输。
    usb_tx_block（） 可以从中断上下文（例如在 HCD 交还路径中）调用，因此我们不能始终使用它来终止正在运行的 URB。通过检查现有 URB 的tx_submitted定位标记，防止在中断上下文期间休眠。我们现在返回 -EBUSY，表示有一个待处理的请求。（CVE-2026-53107）

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

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

  - ipv6：修复 icmpv6_rcv（） 中可能的 UAF 由于 skb->head 可更改，因此在 pskb_pull（） 之前缓存 saddr 和 daddr 是有问题的。删除这些临时变量：- 仅当在慢速路径中调用 net_dbg_ratelimited（） 时，我们才访问 &ipv6_hdr（skb）->saddr 和 &ipv6_hdr（skb）->daddr。- 避免 pskb_pull（） 调用后未来可能的误用。（CVE-2026-53006）

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

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

  - wifi: brcmfmac: 修复错误指针取消引用。函数 brcmf_chip_add_core() 可能返回错误指针，但没有进行检查。添加错误指针的检查。Smatch 检测到：
    drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() 错误：'core' 可能存在取消引用 ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() 错误：'core' 可能存在取消引用 ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() 错误：'core' 可能存在取消引用 ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() 错误：'core' 可能存在取消引用 ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() 错误：'core' 可能存在取消引用 ERR_PTR() [添加缺失的 wifi: prefix] (CVE-2026-53093)

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

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

  - ocfs2：在 freefrag 扫描期间验证bg_bits [缺陷] 构建的文件系统可在随 OCFS2_INFO_FL_NON_COHERENT 一起发出OCFS2_IOC_INFO时触发越界位图遍历。缺陷： KASAN： include/linux/instrumented.h：68 instrument_atomic_read中的释放后使用 [内联] 缺陷： KASAN： include/asm-generic/bitops/instrumented-non-atomic.h：141 _test_bit中的释放后使用 [内联] 缺陷： KASAN： include/asm-generic/bitops/le.h：21 test_bit_le中的释放后使用 [内联] 缺陷： KASAN： ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c：495 中的释放后使用 [内联] 缺陷： KASAN： ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c：588 中的释放后使用 [内联] 缺陷： KASAN：ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c：662 中的释放后使用 [内联] 缺陷： KASAN：在 ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c：754 中通过任务 syz.0.636/1435 在地址 ffff888031bce000 读取的大小为 8 的释放后使用 调用跟踪：__dump_stack lib/dump_stack.c：94 [内联] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c：120 print_address_description mm/kasan/report.c：378 [内联] print_report+0xd1/0x650 mm/kasan/report.c：482 kasan_report+0xfb/0x140mm/kasan/report.c：595 check_region_inline mm/kasan/generic.c：186 [内联] kasan_check_range+0x11c/0x200 mm/kasan/generic.c：200
    __kasan_check_read+0x11/0x20 mm/kasan/shadow.c：31 instrument_atomic_read include/linux/instrumented.h：68 [内联] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h：141 [内联] test_bit_le include/asm-generic/bitops/le.h：21 [内联] ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c：495 [内联] ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c：588 [内联] ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c：662 [内联] ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c：754 ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c：828 ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c：913 vfs_ioctl fs/ioctl.c：51 [内联] __do_sys_ioctl fs/ioctl.c：597 [内联] __se_sys_ioctl fs/ioctl.c：583 [内联]
    __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c：583 ... [原因] ocfs2_info_freefrag_scan_chain（） 直接将磁盘上的bg_bits用作位图扫描限制。一致的路径通过 ocfs2_read_group_descriptor（） 读取群组描述符，进而在使用前验证描述符。非相干路径使用 ocfs2_read_blocks_sync（） 代替并跳过该验证，因此不可能的bg_bits值可以驱动位图遍历通过块的末尾。[修复]使用 ocfs2_group_bitmap_size（） 根据文件系统格式计算位图容量，报告bg_bits超过该限制的描述符，并将扫描限制在计算的容量上。这可使 freefrag 报告持续运行，同时避免读取超出缓冲区。
    (CVE-2026-53040)

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

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

  - powerpc/64s：修复与 PMD 迁移条目的取消映射争用 迁移交换条目或设备专用 THP 条目可能存在以下争用。例如，在 PMD THP 页面上调用 move_pages 时，可能存在中间状态，其中 PMD 条目充当迁移交换条目（pmd_present（） 为真）。然后，如果一个 munmap 同时发生，那么这个 VM_BUG_ON（） 可以在 pmdp_huge_get_and_clear_full（） 中发生。此修补程序修复了该问题。线程 A：move_pages（） syscall add_folio_for_migration（） mmap_read_lock（mm） folio_isolate_lru（folio） mmap_read_unlock（mm） do_move_pages_to_node（） migrate_pages（） try_to_migrate_one（） spin_lock（ptl） set_pmd_migration_entry（） pmdp_invalidate（） # PMD：_PAGE_INVALID |_PAGE_PTE |pfn set_pmd_at（） # PMD：迁移交换条目 （pmd_present=0） spin_unlock（ptl） [页面复制阶段] # <--- RACE WINDOW --> 线程 B：munmap（） mmap_write_downgrade（mm） unmap_vmas（） -> zap_pmd_range（） zap_huge_pmd（）
    __pmd_trans_huge_lock（） pmd_is_huge（）： # ！pmd_present &&; ！pmd_none -> TRUE（交换条目） pmd_lock（） -> # spin_lock（ptl），等待线程 A 释放 ptl pmdp_huge_get_and_clear_full（） VM_BUG_ON（！pmd_present（*pmdp）） # 命中！[ 287.738700][ T1867] ------------[ cut here ]------------ [287.743843][ T1867] arch/powerpc/mm/book3s64/pgtable.c：187！ 处的内核缺陷 CPU 0x0： 矢量：[c00000044037f4f0] pc： c000000000094ca4： pmdp_huge_get_and_clear_full+0x6c/0x23c lr：
    c000000000645dec：zap_huge_pmd+0xb0/0x868 sp：c00000044037f790 MSR：800000000282b033 当前 = 0xc0000004032c1a00 PACA = 0xc000000004fe0000 irqmask：0x03 irq_happened：0x09 PID = 1867，comm = a.out 内核 ：187！Linux 版本 6.19.0-12136-g14360d4f917c-dirty （powerpc64le-linux-gnu-gcc （Debian 12.2.0-14） 12.2.0， GNU ld （GNU Binutils for Debian） 2.40） #27 SMP PREEMPT Sun Feb 22 10：38：56 IST 2026 输入 ？ 寻求帮助 [链接注册] c0000000000645dec zap_huge_pmd+0xb0/0x868 [c000000044037f790] c00000044037f7d0（不可靠） [c000000044037f7d0] c000000000645dcc zap_huge_pmd+0x90/0x868 [c000000044037f840] c0000000005724cc unmap_page_range+0x176c/0x1f40 [c000000044037fa00] c000000000572ea0 unmap_vmas+0xb0/0x1d8[c00000044037fa90] c00000000005af254 unmap_region+0xb4/0x128 [c00000044037fb50] c0000000005af400 vms_complete_munmap_vmas+0x138/0x310 [c00000044037fbe0] c0000000005b0f1c do_vmi_align_munmap+0x1ec/0x238 [c00000044037fd30] c0000000005b3688 __vm_munmap+0x170/0x1f8 [c000000044037fdf0] c000000000587f74 sys_munmap+0x2c/0x40 [c000000044037fe10] c000000000032668 system_call_exception+0x128/0x350 [c000000044037fe50] c00000000000d05c system_call_vectored_common+0x15c/0x2ec ----异常：00000000010064a2c 的 3000（系统调用矢量） SP （7fff9b1ee9c0） 位于用户空间 0：mon>zh commit a30b48bf1b24（mm/migrate_device：实现区域设备页面的 THP 迁移），启用了设备私有 PMD 条目的迁移。因此，这是可从中触发此警告的另一路径。------------[ cut here ]------------ 警告：
    arch/powerpc/mm/book3s64/hash_pgtable.c：199 at hash__pmd_hugepage_update+0x48/0x284， CPU#3： hmm-tests/1905 链接的模块：test_hmm CPU：3 UID：0 PID：1905 Comm：hmm-tests 受感染：G B W L N 7.0.0-rc1-01438-g7e2f0ee7581c #21 PREEMPT 受感染：[B]=BAD_PAGE，[W]=WARN，[L]=SOFTLOCKUP，[N]=TEST 硬件名称：IBM pSeries（由 qemu 模拟）（ POWER10 架构） 0x801200 0xf000006：SLOF，git-ee03ae pSeries NIP [c0000000000096b70] hash__pmd_hugepage_update+0x48/0x284 LR [c0000000000096e7c] hash__pmdp_huge_get_and_clear+0xd0/0xd4 调用跟踪：[c000000604707670] [c000000004e102b8] 0xc000000004e102b8（不可靠） [c000000604707700] [c00000000064ec3c] set_pmd_migration_entry+0x414/0x498 [c0000000604707760] [c00000000063e5a4] migrate_vma_col ---truncated--- （CVE-2026-53108）

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

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

  - netfilter：nfnetlink_osf：修复 ttl 检查中潜在的空取消引用 nf_osf_ttl（） 函数访问 skb->dev 以在未验证设备指针有效性的情况下执行本地接口地址查找。
    此外，该实现利用in_dev_for_each_ifa_rcu循环将数据包源地址与本地接口地址进行匹配。它假设来自相同子网的数据包不应在初始 TTL 上看到递减。数据包可能看起来来自同一子网，但实际上并非如此，尤其是在具有容器和虚拟交换的现代环境中。删除设备取消引用和接口循环。将逻辑替换为 switch 语句，该语句根据ttl_check评估 TTL。（CVE-2026-52998）

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

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

  - ksmbd：修复持久重新连接期间 smb2_open 中的释放后使用 在 smb2_open 中，对 ksmbd_put_durable_fd（fp） 的调用会在持久重新连接进程期间提早终止对持久文件描述符的引用。如果随后出现错误（例如，ksmbd_iov_pin_rsp失败）或清道夫访问该文件，则在访问 fp 属性（如 fp->create_time）时会导致释放后使用。将单个放置移至err_out2下方函数的末尾，以便 fp 保持有效，直到 smb2_open 返回。（CVE-2026-53010）

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

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

  - ice：修复 skb tx_buf的双重释放 如果 ice_tso（） 或 ice_tx_csum（） 失败，则 ice_xmit_frame_ring（） 中的错误路径将释放 skb，但“第一个”tx_buf仍然指向该 skb 并将此标记为有效 （ICE_TX_BUF_SKB）。“next_to_use”保持不变，因此当传输下一个数据包并覆盖tx_buf时，潜在的问题可能会自行解决。但如果没有下一个数据包并且接口被关闭，则 ice_clean_tx_ring（） -> ice_unmap_and_free_tx_buf（） 将找到tx_buf并第二次释放 skb。修复方法是将 tx_buf 类型重置为在错误路径中的 ICE_TX_BUF_EMPTY，以便 ice_unmap_and_free_tx_buf（）。上移“first”的初始化，以确保在其遇到线性化错误路径时已经有效。当我让它寻找其他东西时，人工智能发现了这个错误。并提出了修补程序的初始版本。我重现了该缺陷，并通过添加代码以在具有 KASAN 的版本中注入失败来测试补丁。我在相关的 Intel 驱动程序中查找了类似的缺陷，但没有找到任何缺陷。（CVE-2026-53009）

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

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

  - smb/client：修复 symlink_data（） 中可能的无限循环和 OOB 读取 在 32 位架构上，无限循环如下：len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == p 在 32 位架构上，越界读取如下：len = p->ErrorDataLength == 0xfffffff0 u8 *next = p->ErrorContextData + len next == （u8 *）p - 8 （CVE-2026-52967）

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

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

  - bpf：修复 bpf_fd_array_map_clear（） 中的 RCU 停止 添加 bpf_fd_array_map_clear（） 循环中缺少的 cond_resched（）。对于具有许多条目的 PROG_ARRAY 映射，此循环会针对每个条目调用 prog_array_map_poke_run（），这样可能很昂贵，而且如果不产生此缺陷，则可能导致 RCU 在负载下停止：rcu： 堆栈转储，RCU GP kthread 上次运行的位置： CPU：0 UID：0 PID：30932 Comm：kworker/0:2 未受感染 6.14.0-13195-g967e8def1100 #2 PREEMPT（undef） 工作队列：事件prog_array_map_clear_deferred RIP： 0010：write_comp_data+0x38/0x90 kernel/kcov.c：246 调用跟踪： <TASK> prog_array_map_poke_run+0x77/0x380 kernel/bpf/arraymap.c：1096
    __fd_array_map_delete_elem+0x197/0x310 kernel/bpf/arraymap.c：925 bpf_fd_array_map_clear kernel/bpf/arraymap.c：1000 [内联] prog_array_map_clear_deferred+0x119/0x1b0 kernel/bpf/arraymap.c：1141 process_one_work+0x898/0x19d0 kernel/workqueue.c：3238 process_scheduled_works kernel/workqueue.c：3319 [内联] worker_thread+0x770/0x10b0 kernel/workqueue.c：3400 kthread+0x465/0x880 kernel/kthread.c：464 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c：153 ret_from_fork_asm+0x19/0x30 arch/x86/entry/entry_64.S：245 </TASK> （CVE-2026-53083）

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

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

  - net/sched：cls_fw：修复 change（） 之前旧过滤器的空取消引用 正如 Sashiko [1] 所指出的，自提交 ed76f5edccc9（net：sched：使用 filter_chain_lock 互斥体保护 filter_chain 列表）TC 过滤器被添加到共享区块并在调用其 ->change（） 函数之前发布到 datapath。
    这是 cls_fw 的问题：使用旧方法创建的无效过滤器在被 Xiang 添加的验证逻辑破坏之前仍然可以对某些数据包进行分类。因此，坚持重复运行以下脚本： # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \ > -A 4.3.2.1 -B -t 1.2.3.4 udp dp=1234 -q &; # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link deldev crash0 仍可使 fw_classify（） 命中 [2] 中的 WARN_ON（）： WARNING： ./include/net/pkt_cls.h：88 at fw_classify+0x244/0x250 [cls_fw]， CPU#18： mausezahn/1399 链接的模块： cls_fw（E） act_skbedit（E） CPU： 18 UID： 0 PID： 1399 Comm： mausezahn 受感染： G E 7.0.0-rc6-virtme #17 PREEMPT（full） 受感染： [E]=UNSIGNED_MODULE 硬件名称： Red Hat KVM， BIOS 1.16.3-2.el9 04/01/2014 RIP： 0010：fw_classify+0x244/0x250 [cls_fw] 代码： 5c 49 c7 45 00 00 00 00 00 00 41 5d 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 90 90 90 90 9090 90 90 90 RSP： 0018：ffffd1b7026bf8a8 EFLAGS： 00010202 RAX： ffff8c5ac9c60800 RBX： ffff8c5ac99322c0 RCX： 0000000000000004 RDX： 0000000000000001 RSI： ffff8c5b74d7a000 RDI： ffff8c5ac8284f40 RBP： ffffd1b7026bf8d0 R08： 0000000000000000 R09：
    ffffd1b7026bf9b0 R10： 000000000ffffffff R11： 0000000000000000 R12： 0000000000010000 R13： ffffd1b7026bf930 R14： ffff8c5ac8284f40 R15： 0000000000000000 FS： 00007fca40c37740（0000） GS：ffff8c5b74d7a000（0000） knlGS：000000000000000 CS： 0010 DS： 0000 ES： 0000 CR0： 0000000080050033 CR2： 00007fca40e822a0 CR3：
    0000000005ca0001 CR4：0000000000172ef0 调用跟踪： <TASK> tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150
    __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0
    __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP：0033：0x7fca40e822ba 代码：d8 64 89 02 48 C7 C0 FF FF FF FF EB B8 0F 1F 00 F3 0F 1E FA 41 89 CA 64 8B 04 25 18 00 00 00 85 C0 75 15 B8 2C 00 00 00 00 0F 05 <48> 3D 00 F0 FF FF 77 7E C3 0F1f 44 00 00 41 54 48 83 ec 30 44 89 RSP： 002b：00007ffc248a42c8 EFLAGS： 00000246 ORIG_RAX： 000000000000002c RAX： ffffffda RBX： 000055ef233289d0 RCX： 00007fca40e822ba RDX：
    000000000000001e RSI：000055ef23328c30 RDI：0000000000000003 RBP：000055ef233289d0：00007ffc248a42d0R09：0000000000000010R10：0000000000000000R11：0000000000000246R12：000000000000001eR13：R08
    000000000000186a0 R14： 0000000000000000 R15： 00007fca41043000 </TASK> irq 事件戳： 1045778 hardirqs 上次启用时间（1045784）： [<ffffffff864ec042>] __up_console_sem+0x52/0x60 hardirqs 上次禁用时间（1045789）： [<ffffffff864ec027>] __up_console_sem+0x37/0x60 softirqs 上次启用时间（1045426）：
    [<ffffffff874d48c7>] __alloc_skb+0x207/0x260 softirqs 上次禁用时间 （1045434）： [<ffffffff874fe8f8>]
    __dev_queue_xmit+0x78/0x14d0 然后，由于数据包标记中的值，会发生带有空“q”的“q->handle”上的取消引用：缺陷：内核空指针取消引用，地址：0000000000000038 [...]RIP：
    0010：fw_classify+0x1fe/0x250 [cls_fw] [...]跳过共享区块上的旧式分类，以便修复空取消引用，并且在无效cls_fw旧式过滤器的短生命周期内不会再命中 WARN_ON（）。[1] https://sashiko.dev/#/patchset/2 ---truncated--- （CVE-2026-53080）

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

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

  - netfilter：nf_conntrack_sip：不使用 simple_strtoul 将 epaddr_len（）、ct_sip_parse_header_uri（） 和 ct_sip_parse_request（） 中不安全的端口解析替换为新的 sip_parse_port（） 辅助函数，该辅助函数会根据缓冲区限制来验证每个数字，从而消除使用假定以 NUL 结束的字符串的 simple_strtoul（）。之前的代码在 sip_parse_addr（） 之后取消引用指针而不进行边界检查，并且依赖非 NUL 结束的 skb 数据中的 simple_strtoul（）。达到缓冲区限制且没有结尾字符的端口也会因畸形而遭到拒绝。还删除了连接跟踪中所有 simple_strtoul（） 的使用，而是选择更严格的版本。有意更改：- 如果数字> UINT_MAX并指示失败则退出，对于过长的序列也是如此。尽管我们接受 05535 作为端口 5535，但我们不会接受例如“sip：10.0.0.1:005060”。尽管它在语法上在 RFC 3261 下有效，但我们应限制这一点，以便在出现具有 64k“0”字符的畸形数据包时不浪费周期。- 强制 ct_sip_parse_numerical_param（） 中的基数为 10。这用于提取“expire=”和“rports=”;两者都应使用 base-10。- 在 nf_nat_sip.c 中，仅接受在 1k-64k 范围内的解析值。- 现在，epaddr_len 在端口无效时返回 0，这一点已经针对无效 IP 地址返回。这是有意为之的。
    nf_conntrack_sip会执行大量猜测来找到消息中要解析的正确部分。更严格可能会破坏现有设置。连接跟踪帮助程序旨在允许流量通过，而不是阻断流量。基于 Jenny Guanni Qu <qguanni@gmail.com>提供的较早版本的修补程序。（CVE-2026-52986）

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

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

  - libceph：处理 decode_choose_args（） 中的 rbtree 插入错误 CEPH_MSG_OSD_MAP 类型的消息包含 OSD 映射，其本身也包含 CRUSH 映射。接收到的 CRUSH 映射可选择包含在 decode_choose_args（） 中解码的choose_args。在此函数中，从消息中读取num_choose_arg_maps，然后解码相应数量的crush_choose_arg_maps。每个crush_choose_arg_map都有一个choose_args_index，作为将其插入解码crush_map的choose_args rbtree 时的密钥。如果（可能损坏的）消息包含两个具有相同索引的crush_choose_arg_maps，则当尝试插入第二个crush_choose_arg_map时，insert_choose_arg_map（） 中的断言将触发内核缺陷。此修补程序通过切换到非断言 rbtree 插入函数并在插入失败时拒绝消息来修复此问题。[ idryomov：变更日志 ]（CVE-2026-52954）

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

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

  - ceph：放置不适合进行回写的作品集批处理会保留对作品集的引用（请参见“filemap_get_folios”、“folio_batch_release”），因此我们需要对删除的作品集进行“folio_put”。在 v6.18 上测试。（CVE-2026-52960）

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

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

  - btrfs：修复使用 flushoncommit 时 reflink 和事务提交之间的死锁 使用 flushoncommit 挂载选项时，事务提交与将内联范围复制到目标节点当前i_size之外的偏移量的 reflink 操作之间可发生死锁。死锁的情况如下：1） 任务 A 将内联范围从 inode X 克隆到 inode Y 的偏移量，该偏移量超出了 Y 的当前i_size。这意味着我们使用对 copy_inline_to_page（） 的调用将内联范围的数据复制到其 EOF 之外的 inode Y 的作品集;2）任务 B 启动事务提交并调用 btrfs_start_delalloc_flush（） 以刷新 delalloc;3） delalloc 刷新看到 inode Y 的新脏作品集，当它尝试刷新它时，它会在 extent_writepage（） 结束，并发现该作品集的偏移超出了 inode Y 的i_size，因此它尝试通过调用 folio_invalidate（） 来使该作品集无效，这将在 btrfs 的作品集无效回调 - btrfs_invalidate_folio（） 结束。在那里，它尝试在 inode Y 的盘区 io 树中锁定作品集的范围，但由于当前由任务 A 锁定而阻断 - 在引用链接期间，我们在刷新所有 delalloc 并等待有序盘区完成之后锁定 inode、源和目标范围 - 之后我们不希望在范围中存在脏作品集， 例外情况是，如果我们必须复制内联范围的数据（因为目标偏移量不是零）;4） 然后任务 A 尝试启动事务以更新 inode 项，然后由于当前事务处于TRANS_STATE_COMMIT_START状态而被阻止。因此，任务 A 必须等待当前事务被解锁（其状态 >= TRANS_STATE_UNBLOCKED）。因此，任务 A 正在等待任务 B 完成的事务提交，而后者则在等待任务 A 当前持有的 inode Y 的范围锁定。Syzbot 最近通过以下堆栈跟踪报告了这一点：INFO：任务 kworker/u8：7：1053 被阻塞超过 143 秒。未受感染 syzkaller #0 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。 task：kworker/u8：7 state：D stack：23520 pid：1053 tgid：1053 ppid：2 task_flags：0x4208060 flags：0x00080000 工作队列：writeback wb_workfn （flush-btrfs-46） 调用跟踪： <TASK> context_switch kernel/sched/core.c：5298 [内联] __schedule+0x1553/0x5240 kernel/sched/core.c：6911 __schedule_loop kernel/sched/core.c：6993 [内联] schedule+0x164/0x360 kernel/sched/core.c：7008 wait_extent_bitfs/btrfs/extent-io-tree.fs/extentc：811 [内联] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c：1914 btrfs_lock_extent fs/btrfs/extent-io-tree.h：152 [内联] btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c：7704 extent_writepage fs/btrfs/extent_io.c：1852 [内联] extent_write_cache_pages fs/btrfs/extent_io.c：2580 [内联] btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c：2713 do_writepages+0x32e/0x550 mm/page-writeback.c：2554 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.。 c：1750 writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c：2042 wb_writeback+0x456/0xb70 fs/fs-writeback.c：2227 wb_do_writeback fs/fs-writeback.c：2374 [内联] wb_workfn+0x41a/0xf60 fs/fs-writeback.c：2414 process_one_work kernel/workqueue.c：3276 [内联] process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c：3359 worker_thread+0xa53/0xfc0 kernel/workqueue.c：3440 kthread+0x388/0x470 kernel/kthread.c：436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c：158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S：245 </TASK> INFO：任务 syz.4.64:6910 阻断超过 143 秒。未受感染 syzkaller #0 echo 0 > /proc/sys/kernel/hung_task_timeout_secs 禁用此消息。
    task：syz.4.64 state：D stack：22752 pid：6910 tgid： ---truncated--- （CVE-2026-53122）

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

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

  - fs/omfs：拒绝小于 OMFS_DIR_START omfs_fill_super（） 的s_sys_blocksize拒绝超大的 s_sys_blocksize 值 （> PAGE_SIZE），但不会拒绝小于 OMFS_DIR_START （0x1b8 = 440） 的值。之后，omfs_make_empty（） 使用 sbi->s_sys_blocksize - OMFS_DIR_START 作为 memset（） 的长度参数。由于 s_sys_blocksize 为 u32，构建的带 s_sys_blocksize < OMFS_DIR_START 的文件系统图像会导致无符号下溢，封装到接近 2^32 的值。这会从 bh->b_data + OMFS_DIR_START 驱动 ~4 GiB memset（），并且覆盖的内核内存远远超出后备块缓冲区。在 omfs_fill_super（） 中添加相应的下界检查和现有的上界检查，以便在处理任何文件系统数据之前，在超级块验证期间拒绝畸形图像。
    (CVE-2026-53130)

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

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

  - dm cache：修复传递模式下的写入挂起 invalidate_remove（） 函数在缓存失效后处理写入命中 bios 的逻辑不完整。它设置了 overwrite_bio的重新映射，但随后在不提交的情况下立即将其丢弃，从而导致写入操作挂起。通过添加新的 invalidate_committed（） 延续来修复，该延续在元数据提交完成后将重新映射的写入提交到缓存原始点，同时使用 overwrite_endio 挂钩确保正确的完成排序。这保持了现有的一致性。还改进了 invalidate_complete（） 中的错误处理，以保留原始错误状态，而不是无条件使用 bio_io_error（）。（CVE-2026-53063）

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

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

  - efi/capsule-loader：修复 phys 数组重新分配中错误的 sizeof __efi_capsule_setup_info（） 中对 cap_info->phys 的 krealloc（） 调用使用 sizeof（phys_addr_t *） 而非 sizeof（phys_addr_t），这可能导致分配过小。此分配也不符合 efi_capsule_open（） 中的初始数组分配（使用 sizeof（phys_addr_t） 分配一个条目），以及通过 page_to_phys（） 存储phys_addr_t值（而非指针）的 efi_capsule_write（） 函数。在 sizeof（phys_addr_t） == sizeof（phys_addr_t * ） 的 64 位系统上，此问题不会被注意到。在具有 PAE 的 32 位系统上，其中 phys_addr_t 是 64 位但指针是 32 位，这样会分配所需空间的一半，存储物理地址时可导致堆缓冲区溢出。这与提交 fccfa646ef36 中修复的缺陷类似（efi/capsule-loader：修复不正确的分配大小），后者在初始分配站点修复了相同问题。（CVE-2026-53047）

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

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

  - drbd：平衡 drbd_adm_dump_devices（） 中的 RCU 调用 先使 drbd_adm_dump_devices（） 调用 rcu_read_lock（），然后再调用 rcu_read_unlock（）。Clang 线程安全分析器已检测到此问题。
    (CVE-2026-53128)

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

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

  - ocfs2：缓存前验证群组添加输入 [BUG] OCFS2_IOC_GROUP_ADD可在 ocfs2_set_new_buffer_uptodate（） 中触发BUG_ON：fs/ocfs2/uptodate.c：509！哎呀：无效操作码：0000 [#1] SMP KASAN NOPTI RIP：0010：ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c：509 代码：ffffe88f 42b9fe4c 89e64889 dfe8b4df 调用跟踪：ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c：507 ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c：887 vfs_ioctl fs/ioctl.c：51 [内联] __do_sys_ioctl fs/ioctl.c：597 [内联] __se_sys_ioctl fs/ioctl.c：583 [内联] __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 RIP：0033：0x7bbfb55a966d [原因] ocfs2_group_add（） 会在 ocfs2_verify_group_and_input（） 验证某个用户控制的群组块上调用该块数之前，（） 会调用该块上的 ocfs2_set_new_buffer_uptodate（）。该帮助程序仅对新分配的元数据有效，并断言所选元数据缓存中尚未存在该块。即使群组描述符属于 main_bm_inode，代码也使用 INODE_CACHE（inode），并且以后的日志访问改用该缓存上下文。[修复]在缓存磁盘上的群组描述符之前对其进行验证，然后将其添加到 INODE_CACHE（main_bm_inode） 跟踪的元数据缓存中。将验证失败路径与后续清理路径保持独立，这样我们只在实际插入缓冲区之后才从该缓存删除缓冲区。这使组缓冲区生命周期在验证、日志记录和清理过程中保持一致。（CVE-2026-53039）

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

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

  - nvmet-tcp：将 nvmet_tcp_build_pdu_iovec（） 错误传播给调用程序 目前，当 nvmet_tcp_build_pdu_iovec（） 检测到越界 PDU 长度或偏移时，会触发 nvmet_tcp_fatal_error（cmd->queue） 并提早返回。但是，由于该函数返回 void，因此调用程序完全不知道已发生严重错误以及 cmd->recv_msg.msg_iter 处于未初始化状态。nvmet_tcp_handle_h2c_data_pdu（） 等调用程序会盲目地以 queue->rcv_state = NVMET_TCP_RECV_DATA 覆盖队列状态。因此，套接字接收循环可能尝试将传入的网络数据读入未初始化的迭代器中。通过将错误处理责任转移给调用方来修复此问题。（CVE-2026-52989）

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

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

  - net：pull qdisc_pkt_len_segs_init（） 中的标头 大多数 ndo_start_xmit（） 方法预期 gso 数据包的标头已在 skb->head 中。net/core/tso.c 用户尤其面临风险，因为 tso_build_hdr（） 执行 memcpy（hdr， skb->data， hdr_len）;qdisc_pkt_len_segs_init（） 已执行 GSO 数据包的解析。使用 pskb_may_pull（） 而不是 skb_header_pointer（） 以确保驱动程序不必重新实现此操作。可馈送某些恶意数据包，检测它们，以便我们借助新SKB_DROP_REASON_SKB_BAD_GSO drop_reason更快地删除它们。（CVE-2026-53091）

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

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

  - blk-cgroup：修复 blkcg_maybe_throttle_current（） 中的磁盘引用泄漏 添加 blkcg_maybe_throttle_current（） 中错误路径上缺失的 put_disk（）。当 blkcg 查找、blkg 查找或 blkg_tryget（） 失败时，该函数会跳转到 out 标签，其仅调用 rcu_read_unlock（） 而不会释放 blkcg_schedule_throttle（） 通过 get_device（） 所取得的磁盘引用。由于在查找之前 current->throttle_disk 已设置为 NULL，blkcg_exit（） 也无法释放该引用，从而导致永远不会释放磁盘。还原原始代码中作为 blk_put_queue（） 存在但在从 request_queue 到 gendisk 的转换期间无意间丢弃的参考版本。（CVE-2026-53126）

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

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

  - wifi：mt76：修复破坏设备的 MT76 内存泄漏 即使队列未与 NAPI 关联，所有 rx 队列都有一个关联的page_pool（例如启用了 WED 的 WED RRO 队列）。在模块卸载期间破坏运行mt76_dma_cleanup例程page_pool。此外，如果未为 WED RRO 队列启用 WED，则将页面返回到页面池。（CVE-2026-53104）

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

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

  - Mistune 是一个包含渲染器和插件的 Python Markdown 解析器。在之前的版本 3.3.0之前，Mistune 容易受到 CPU 耗尽 DoS 影响，这是因为 parse_link_text 中的超线性（约 O（n））行为所致。解析包含许多连续 [ 字符的 Markdown 时，parse_link_text 会使用循环内的 regex 搜索反复扫描输入。每次迭代都会重新扫描大部分剩余字符串，从而导致二次时间行为。因此，攻击者控制的 Markdown 输入可以用非常小的负载触发过度 CPU 使用。此漏洞已在 3.3.0 中修复。(CVE-2026-49851)

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

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

  - Bluetooth：l2cap：添加 l2cap_ecred_reconf_rsp l2cap_ecred_reconf_rsp（） 调用 l2cap_chan_del（） 而不按住 l2cap_chan_lock（） 时缺少的 chan 锁定。文件中所有其他 l2cap_chan_del（） 调用程序首先获取锁定。远程 BLE 设备可在另一个线程迭代通道列表时发送构建的 L2CAP ECRED 重新配置响应以损坏通道列表。在 l2cap_chan_del（） 之前添加 l2cap_chan_hold（） 和 l2cap_chan_lock（），并在之后添加 l2cap_chan_unlock（） 和 l2cap_chan_put（），以匹配 l2cap_ecred_conn_rsp（） 和 l2cap_conn_del（） 中使用的模式。（CVE-2026-53071）

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

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

  - OpenColorIO 是用于视觉效果和动画的颜色管理框架。在低于版本之前 2.5.2，“FileFormatSpi3D.cpp：163”在解析 LUT 数据行时将“sscanf”与“%s”用于 64 字节堆栈缓冲区。
    输入来自“lineBuffer[4096]”，因此构建的 .spi3d 文件在非 Windows 上可溢出 ~4000 字节。
    版本 2.5.2 已修复该问题。(CVE-2026-42450)

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

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

  - 1.3.9b 和 1.3.10rc2 及之前版本的 ProFTPD 中包含访问控制绕过漏洞，允许经认证的 FTP 用户通过在 RNFR 命令处理程序中以 /proc/self/root 作为前缀的路径来避开目录 ACL 限制。攻击者可利用 dir_canonical_path（） 中未解析的符号链接组件导致 dir_check（） 执行不匹配任何配置的目录块的词汇路径比较，从而对 DenyAll-protected 目录中的文件执行重命名操作，然后检索这些文件。缓解：使用 DefaultRoot （chroot） 配置的会话不受影响，因为 chroot 会更改 /proc/self/root 解析到的目录。（CVE-2026-35025）

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

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

  - greybus：raw：修复 cdev 关闭时的释放后使用 这解决了原始捆绑断开连接但其 chardev 仍由应用程序打开时的释放后使用缺陷。当应用程序释放 cdev 时，如果启用了 init on free （CONFIG_INIT_ON_FREE_DEFAULT_ON=y），则会造成以下错误：refcount_t：
    下溢;释放后使用。警告：CPU：0 PID：139 at lib/refcount.c：28 refcount_warn_saturate+0xd0/0x130 ... 调用跟踪： <TASK> cdev_put+0x18/0x30 __fput+0x255/0x2a0 __x64_sys_close+0x3d/0x80 do_syscall_64+0xa4/0x290 entry_SYSCALL_64_after_hwframe+0x77/0x7f cdev 包含在断开连接操作中释放的 gb_raw 结构中。当以后释放 cdev 时，cdev_put会获得指向已释放内存的地址。要修复此释放后使用错误，请将结构设备从指针转换为嵌入设备，这样使 cdev 和此设备的生命周期相同。然后，使用 cdev_device_add，可保证在释放对 cdev 的所有引用之前不会释放设备。最后，将结构的释放委托给设备释放函数，而不是在断开连接回调中立即释放。（CVE-2026-53025）

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

ID	名称	严重性
322719	Linux Distros 未修补的漏洞：CVE-2026-53041	high
322718	Linux Distros 未修补的漏洞：CVE-2026-53000	high
322717	Linux Distros 未修补的漏洞：CVE-2026-53065	medium
322716	Linux Distros 未修补的漏洞：CVE-2026-56368	medium
322715	Linux Distros 未修补的漏洞：CVE-2026-52999	critical
322714	Linux Distros 未修补的漏洞：CVE-2026-52991	high
322713	Linux Distros 未修补的漏洞：CVE-2026-53018	medium
322712	Linux Distros 未修补的漏洞：CVE-2026-53101	medium
322711	Linux Distros 未修补的漏洞：CVE-2026-53109	high
322710	Linux Distros 未修补的漏洞：CVE-2026-52983	high
322709	Linux Distros 未修补的漏洞：CVE-2026-54297	high
322708	Linux Distros 未修补的漏洞：CVE-2026-52957	high
322707	Linux Distros 未修补的漏洞：CVE-2026-53129	high
322706	Linux Distros 未修补的漏洞：CVE-2026-53113	medium
322705	Linux Distros 未修补的漏洞：CVE-2026-53115	high
322704	Linux Distros 未修补的漏洞：CVE-2026-54906	low
322703	Linux Distros 未修补的漏洞：CVE-2026-53089	high
322702	Linux Distros 未修补的漏洞：CVE-2026-54905	low
322701	Linux Distros 未修补的漏洞：CVE-2026-53125	medium
322700	Linux Distros 未修补的漏洞：CVE-2026-52956	high
322699	Linux Distros 未修补的漏洞：CVE-2026-53070	high
322698	Linux Distros 未修补的漏洞：CVE-2026-53107	medium
322697	Linux Distros 未修补的漏洞：CVE-2026-53006	high
322696	Linux Distros 未修补的漏洞：CVE-2026-53093	medium
322695	Linux Distros 未修补的漏洞：CVE-2026-53040	high
322694	Linux Distros 未修补的漏洞：CVE-2026-53108	medium
322693	Linux Distros 未修补的漏洞：CVE-2026-52998	high
322692	Linux Distros 未修补的漏洞：CVE-2026-53010	critical
322691	Linux Distros 未修补的漏洞：CVE-2026-53009	high
322690	Linux Distros 未修补的漏洞：CVE-2026-52967	high
322689	Linux Distros 未修补的漏洞：CVE-2026-53083	medium
322688	Linux Distros 未修补的漏洞：CVE-2026-53080	medium
322687	Linux Distros 未修补的漏洞：CVE-2026-52986	critical
322686	Linux Distros 未修补的漏洞：CVE-2026-52954	high
322685	Linux Distros 未修补的漏洞：CVE-2026-52960	high
322684	Linux Distros 未修补的漏洞：CVE-2026-53122	medium
322683	Linux Distros 未修补的漏洞：CVE-2026-53130	high
322682	Linux Distros 未修补的漏洞：CVE-2026-53063	medium
322681	Linux Distros 未修补的漏洞：CVE-2026-53047	medium
322680	Linux Distros 未修补的漏洞：CVE-2026-53128	medium
322679	Linux Distros 未修补的漏洞：CVE-2026-53039	medium
322678	Linux Distros 未修补的漏洞：CVE-2026-52989	high
322677	Linux Distros 未修补的漏洞：CVE-2026-53091	high
322676	Linux Distros 未修补的漏洞：CVE-2026-53126	medium
322675	Linux Distros 未修补的漏洞：CVE-2026-53104	medium
322674	Linux Distros 未修补的漏洞：CVE-2026-49851	high
322673	Linux Distros 未修补的漏洞：CVE-2026-53071	high
322672	Linux Distros 未修补的漏洞：CVE-2026-42450	high
322671	Linux Distros 未修补的漏洞：CVE-2026-35025	high
322670	Linux Distros 未修补的漏洞：CVE-2026-53025	high

检测

Nessus 的 Misc. 系列

high

high

medium

medium

critical

high

medium

medium

high

high

high

high

high

medium

high

low

high

low

medium

high

high

medium

high

medium

high

medium

high

critical

high

high

medium

medium

critical

high

high

medium

high

medium

medium

medium

medium

high

high

medium

medium

high

high

high

high

high