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

  - MongoDB Server 的查询子系统中的一个问题可允许具有读取权限的经认证的用户通过提交特别构建的查询过滤器造成服务器进程意外终止。此问题可导致拒绝服务。（CVE-2026-18701）

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

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

  - net：enetc：修复当 num_vsi 为 0 时潜在的除以零 对于 i。MX94 系列中，所有独立的 ENETC 都不支持 SR-IOV，因此 pf->caps.num_vsi 为零。当在PF和VF之间分配环时，这会导致enetc4_default_rings_allocation（）中出现除零。除以零是 C 语言中未定义的行为。启用时 ARM64，UDIV/SDIV 指令会静默返回零，而不是引发异常，因此此问题不会导致明显的崩溃。但是，依赖此行为并不正确，并且会带来跨平台兼容性风险。添加针对 num_vsi == 0 的显式检查，并在配置 PF 的环之后提早返回。（CVE-2026-80610）

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

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

  - 已修复 Linux 内核中的下列漏洞：ntfs: bound the look-ahead attribute-list entry in ntfs_external_attr_find() When resolving an attribute lookup with a non-zero @lowest_vcn, ntfs_external_attr_find() peeks at the next $ATTRIBUTE_LIST entry to decide whether to keep searching, but bounds that not-yet-validated entry only with (u8 *)next_al_entry + 6 < al_end (which proves just bytes 0..6 are in range) and (u8 *)next_al_entry + length <= al_end with an attacker-controlled, non-8-aligned length. It then reads next_al_entry->lowest_vcn (an __le64 at offset 8) and the name at next_al_entry->name_offset, both of which can lie past al_end -- the exact end of the kvmalloc'd attribute-list buffer (allocated at the on-disk attr_list_size, no rounding). A crafted on-disk $ATTRIBUTE_LIST whose last entry sits a few bytes before al_end therefore yields a slab out-of-bounds read when the inode is read. Validate the look-ahead entry with ntfs_attr_list_entry_is_valid() (added in patch 1/3) before dereferencing lowest_vcn and the name, so the same fixed-header, length and name bounds the main attribute-list walk uses now guard this read too. (CVE-2026-80673)

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

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

  - Input：ims-pcu - 修复 CDC union 描述符解析中潜在的无限循环 驱动程序通过迭代额外的描述符数据来解析 ims_pcu_get_cdc_union_desc（） 中的 CDC union 描述符。但是，它不会验证每个描述符的 bLength 是否至少为 2。恶意设备可提供 bLength = 0 的描述符，从而导致驱动程序中的无限循环。添加检查以确保 bLength 至少为 2，然后再继续解析。（CVE-2026-80594）

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

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

  - PCI：dwc：避免无 RAS DES 功能时的 dwc_pcie_rasdes_debugfs_deinit（） 空取消引用 dwc_pcie_rasdes_debugfs_init（） 在控制器没有 RAS DES 功能时返回成功，使 pci->debugfs->rasdes_info 未设置。通用 debugfs 拆卸路径仍会调用 dwc_pcie_rasdes_debugfs_deinit（），这会无条件取消引用rasdes_info。未分配 RAS DES 状态时提早返回。在此情况下，不会初始化任何 RAS DES 互斥体，因此不会破坏任何内容。
    [mani：改写的主题]（CVE-2026-80621）

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

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

  - accel/amdxdna：修复设备删除期间的 iommu 域生命周期争用 启用force_iova模式时，amdxdna_remove（） 释放 xdna->domain。如果在删除设备后调用 amdxdna_gem_obj_free（），它可能尝试访问 xdna->domain，从而导致释放后使用。通过将释放 xdna->domain 添加为受管版本操作修复争用，以便其生命周期由 DRM 管理并一直保持有效，直到释放所有受管资源为止。（CVE-2026-80608）

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

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

  - Nodemailer 之前 8.0.8 通过 rejectUnauthorized： false 在 lib/fetch/index.js 中禁用 TLS 证书验证，从而允许攻击者拦截 OAuth2 标记请求。处于中间机器位置的攻击者可能会捕获 OAuth 客户端密码、刷新标记，以及通过被破坏的 HTTPS 连接传输的访问标记。（CVE-2026-82662）

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

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

  - MongoDB Server 的 $graphLookup 聚合阶段中的一个问题可允许经过认证的用户发出聚合和内存管理命令，从而导致在释放底层内存后使用内部引用。这可能导致服务器崩溃或执行非预期代码。（CVE-2026-18706）

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

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

  - Nodemailer 之前 8.0.9 在 jsonTransport 的消息规范化期间无法强制执行 disableFileAccess 和 disableUrlAccess 选项。攻击者可通过在消息内容字段中提供路径或 href 值来读取本地文件或获取 URL，从而绕过预期访问控制。（CVE-2026-82660）

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

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

  - 捆绑 libxml2 2.12.6之前1.16.5的 Nokogiri 版本，受到 libxml2 的 xmllint 工具的影响CVE-2024-34459。Nokogiri 1.16.5 将捆绑的 libxml2 升级到 2.12.7 以解决此问题。根据维护人员的说法，对 Nokogiri 用户不存在影响，因为 Nokogiri 未提供或公开问题发生的 xmllint 工具。（CVE-2024-58377）

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

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

  - wifi：wlcore：启用正确的密码组 提交 c34dbc5900b0 中引入的针对 IGTK 的固件版本号检查（wifi：wlcore：添加对 IGTK 密钥的支持）让每次启动过旧固件时密码数量减少，这确实正在发生。它也没有考虑 wl18xx 以外的其他芯片。在某些 wl128x 上，通过 nm 连接到公共 ap 时可观察到以下情况： [ 484.113311] wlcore： 警告无法设置密钥 [ 484.117828] wlcore： 错误 无法添加或替换密钥 [ 484.123016] wlan0： 无法将密钥 （5， ff：ff：ff：ff：ff） 设置到硬件 （-5） 484.123046[ ] wlcore： 硬件恢复正在进行中。FW 版本：修订版 7.3.10.0.142 [ 484.139923] wlcore：pc：0x0、hint_sts：
    0x00000048计数：1 [ 484.145721] wlcore：停止 [ 484.148986] ieee80211 phy0： 已请求硬件重新启动 [ 484.610473] wlcore：固件已启动 （Rev 7.3.10.0.142） [ 484.633758] wlcore： 关联已完成。[ 484.690490] wlcore： ERROR 命令执行失败 14 [ 484.690490] ------------[ cut here]------------ [ 484.700195] WARNING： drivers/net/wireless/ti/wlcore/main.c：872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore]， CPU#0： kworker/0:0/892 这样无止尽地重复。始终禁用 wl12xx 上的 IGTK 并修复递减的混乱。（CVE-2026-80641）

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

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

  - 已修复 Linux 内核中的下列漏洞：mm: mglru: fix stale batch updates after memcg reparenting The mglru page table walker batches per-generation size deltas in walk->nr_pages while walking page tables without holding the lruvec lock. The reset_batch_size() later folds those deltas into walk->lruvec under the lruvec lock. The page table walker can run concurrently with the memcg reparenting path as follows: CPU0 CPU1 ==== ==== walk_mm --> walk_page_range --> update_batch_size --> walk->nr_pages += delta mem_cgroup_css_offline --> memcg_reparent_objcgs --> lock lruvec lru_gen_reparent_memcg --> reparent child folios to parent unlock lruvec lock lruvec reset_batch_size --> child lrugen->nr_pages += delta This will trigger the following warning in lru_gen_exit_memcg():
    VM_WARN_ON_ONCE(memchr_inv(lruvec->lrugen.nr_pages, 0, sizeof(lruvec->lrugen.nr_pages))); And the user-visible impact of underestimated nr_pages in MGLRU was premature OOMs because MGLRU does not try to reclaim memory when nr_pages reaches zero, but there are still more pages. To fix it, make reset_batch_size() check CSS_DYING under RCU before flushing the pending batch. A non-dying memcg keeps the original lruvec stable against RCU-delayed offlining; a dying memcg redirects the deltas to the first non-dying ancestor. (CVE-2026-80719)

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

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

  - MongoDB Server 的 Atlas 矢量搜索功能中的一个问题可允许对一个视图具有读取访问权限的经过认证的用户从同一底层集合上其他受保护的视图中检索文档。这是由于构造转发到搜索进程的内部请求时未充分处理用户提供的字段所致。（CVE-2026-18705）

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

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

  - mtd：maps：vmu-flash：修复初始化中的空指针取消引用 mtd_info包含必须链接到其父级的结构设备。否则，MTD 的初始化将失败并出现空指针取消引用。（CVE-2026-80597）

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

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

  - MongoDB Server 的地理空间验证中的问题可允许具有写入权限的经认证的用户通过对使用某种类型验证器的集合的并发操作，导致在释放底层内存后使用内部引用。这可导致服务器崩溃，从而造成拒绝服务。（CVE-2026-18700）

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

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

  - ufs：core：跟踪：不取消引用 TP_printk（） 中的指针 drivers/ufs/core/ufs_trace.h 中的跟踪事件被转换为将指向 hba 结构的指针作为跟踪点的参数，然后在 TP_printk（） 中将环形缓冲区的dev_name打印转换为使用 HBA 保存的指针中的 dev 取消引用指针。这是不允许的，因为从 /sys/kernel/tracing/trace 文件读取跟踪事件时会执行 TP_printk（）。这可能会在字面上发生，几秒钟、几分钟、几小时、几周、几天甚至几个月后！无法保证在读取跟踪文件时取消引用 hba 指针时 hba 指针仍然存在。相反，在调用跟踪点时保存 hba 指针中的设备名称，并将其放入环缓冲区事件中。然后 TP_printk（） 可直接从环缓冲区读取名称，并消除读取已释放指针并造成内核崩溃的可能性。此漏洞是在测试用于查找执行非法非引用的 TP_printk（） 参数的跟踪事件代码时检测到的[1] [1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/ （CVE-2026-80661）

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

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

  - Ubuntu Linux - 安全更新 （CVE-2026-81497）

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

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

  - 恢复 PCI/MSI：出错时取消映射 MSI-X 区域 这会恢复提交 1a8d4c6ecb4c81261bcdf13556abd4a958eca202。提交 1a8d4c6ecb4c（PCI/MSI：出错时取消映射 MSI-X 区域）在 msix_capability_init（） 的错误路径上添加了 iounmap（dev->msix_base），用于在 msix_setup_interrupts（） 失败时释放 MSI-X 区域。当 msix_setup_interrupts（） 失败时，调用链为：
    msix_setup_interrupts（） -> __msix_setup_interrupts（） struct pci_dev *dev __free（free_msi_irqs） = __dev;
    ...返回 ret;__free 清理在出错时触发 __free（free_msi_irqs） 清理会调用 pci_free_msi_irqs（），后者已经处理了 unmap： void pci_free_msi_irqs（struct pci_dev *dev） {pci_msi_teardown_msi_irqs（dev）; if （dev->msix_base） { iounmap（dev->msix_base）; // 已在此处取消映射 dev->msix_base = NULL; // 并设置为 NULL } } 因此，dev->msix_base 会取消映射并设置为 NULL，然后 msix_setup_interrupts（） 才会返回到 msix_capability_init（）。提交 1a8d4c6ecb4c（PCI/MSI：出错时取消映射 MSI-X 区域）引入的 goto out_unmap随后在空指针上再次调用 iounmap（）。运行 tools/testing/selftests/kexec/test_kexec_jump.sh 时，已在 Intel Emerald Rapids（192 个 CPU）上重现此操作： 警告： CPU#44 at iounmap+0x2a/0xe0 RIP：
    0010：iounmap+0x2a/0xe0 RDI：0000000000000000 调用跟踪：msix_capability_init+0x317/0x3f0
    __pci_enable_msix_range+0x21d/0x2c0 pci_alloc_irq_vectors_affinity+0xa9/0x130 nvme_setup_io_queues+0x2a8/0x420 [nvme] nvme_reset_work+0x151/0x340 [nvme] ... RDI=0 确认 iounmap（） 的调用具有 NULL 权限。还原原始的 goto out_disable并将取消映射保留为现有
    __free（free_msi_irqs） 清理。（CVE-2026-80620）

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

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

  - batman-adv：dat：确保 proto 字段eth_hdr可访问 batadv_get_vid（） 访问以太网标头的 proto 字段时，并不检查数据本身是否可访问。调用者应对此问题负责。但与其他调用网站相反，batadv_dat_get_vid（） 及其调用者并未确保这是真实的。此问题可造成越界访问。（CVE-2026-80599）

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

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

  - 在 FLVMeta 及之前 1.2.2版本中确定一个漏洞。组件 AMF Object Parsing 的 src/amf.c 文件的函数amf_object_get受到此漏洞的影响。此操作导致空指针取消引用。攻击可从远程发起。该漏洞已被公开披露，可能会被利用。修补程序名称：52642f7dfb76ec7334016622dde60b1ae963d79b。若要修复此问题，建议部署修补程序。项目维护者怀疑其安全性影响：虽然我已确认这些缺陷并提供了补丁，但我尚未发现任何可利用这些所谓漏洞的方法。（CVE-2026-82821）

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

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

  - Input：ims-pcu - 添加响应长度检查 驱动程序会处理来自设备缓冲区的响应数据，而未验证设备实际上是否发送了足够的数据。这可能导致越界读取或处理过时数据。添加访问缓冲区之前的预期响应长度检查。（CVE-2026-80595）

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

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

  - ipv6：防止 __in6_dev_stats_get（） 中可能的空取消引用，如果原始物理设备未注册，dev_get_by_index_rcu（） 可能返回 NULL。由 Sashiko 发现。（CVE-2026-80646）

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

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

  - Bluetooth：sco：修复 sco_sock_timeout（） 中的争用条件 sco_sock_timeout（） 异步运行且 lock_sock（sk）。如果套接字在计时器运行时关闭，它会持有相同锁定 （lock_sock（sk）） 两次，导致死锁。CPU 0 CPU 1 ==================== ====================== sco_sock_close（） sco_sock_timeout（） lock_sock（sk） // <-- LOCK __sco_sock_close（） sco_chan_del（） sco_conn_put（） sco_conn_free（） disable_delayed_work_sync（） lock（sk） // <-- SAME LOCK 通过将 disable_delayed_work_sync（） 移到 lock_sock（sk） 之外，确保在 sco_sock_timeout（） 之前不保留任何 lock_sock（sk），修复此问题。Lockdep splat：警告：检测到可能的循环锁定依赖 6.13.0-rc4 #7 未受感染 syz-executor292/9514 is is trying to acquire lock： ffff8881115d5070 （（work_completion）（&（&conn->timeout_work）->work））{+.+.}-{0:0}， at： rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h：337 [inline] ffff8881115d5070 （（work_completion）（&（&conn->timeout_work）->work））{+.+.}-{0:0}， at： rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h：849 [inline] ffff8881115d5070 （（work_completion）（&（&conn->timeout_work）->work））{+.+.}-{0:0}， at： start_flush_work sect/v6.13-rc4/kernel/workqueue.c：4137 [inline] ffff8881115d5070 （（work_completion）（&（&conn->timeout_work）->work））{+.+.}-{0:0}， at： __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c：4195 但任务已保持锁定： ffff88807db3a258 （sk_lock-AF_BLUETOOTH-BTPROTO_SCO）{+.+.}-{0:0}， at： lock_sock sect/v6.13-rc4/./include/net/sock.h：1623 [inline] ffff88807db3a258 （sk_lock-AF_BLUETOOTH-BTPROTO_SCO）{+.+.}-{0:0}， at： sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c：524，该锁定已依赖新锁定。 现有依赖关系链（顺序相反）为：-> #1 （sk_lock-AF_BLUETOOTH-BTPROTO_SCO）{+.+.}-{0:0}：
    lock_acquire+0x1c4/0x520 sect/v6.13 13-rc4/kernel/locking/lockdep.c：5849 lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c：3622 lock_sock sect/v6.13-rc4/./include/net/sock.h：1623 [inline] sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c：158 process_one_work sect/v6.13-rc4/kernel/workqueue.c：3229 [inline] process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c：3310 worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c：3391 kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c：389 ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c：147 ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S：244 -> #0 （（work_completion）（&（&conn->timeout_work）->work））{+.+.}-{0:0}： check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c：3161 [inline] check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c：3280 [inline] validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c：3904 __lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c：5226 lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c：5849 touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c：3909 [inline] start_flush_work sect/v6.13-rc4/kernel/workqueue.v6.13-rc4/kernel/workqueue.c：4163 [inline] __flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c：4195 __cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c：4351 [inline] disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c：4514 sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c：95 [inline] kref_put sect/v6.13-rc4/./include/linux/kref.h：65 [inline] sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c：107 sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c：236 sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c：526 sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/blueto ---truncated--- （CVE-2026-80666）

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

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

  - 在 WebKitGTK 中发现一个缺陷。处理恶意 Web 内容可因不正确的内存处理而导致内存损坏。（CVE-2026-83596）

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

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

  - samples/damon/mtier：地址范围参数无效时提早失败 “struct damon_region”顶部的注释明确表示，对于任何用例，@ar都应为非零正大小。现在 damon_verify_new_region（） 中验证内核是否使用 DAMON_DEBUG_SANITY 构建。如果在 node{0,1}_{start，end}_addr 正确初始化之前启用 mtier 示例模块，则可触发 WARN_ONCE（），这显然不好。------------[ cut here ]------------ start 0 >= end 0 警告：
    mm/damon/core.c：217 at damon_new_region+0xf4/0x118， CPU#59： bash/341468 调用跟踪：
    damon_new_region+0xf4/0x118 （P） damon_set_regions+0xfc/0x3c0 damon_sample_mtier_build_ctx+0xe8/0x3a8 damon_sample_mtier_start+0x1c/0x90 damon_sample_mtier_enable_store+0x98/0xb0 param_attr_store+0xb4/0x128 module_attr_store+0x2c/0x50 sysfs_kf_write+0x58/0x90 kernfs_fop_write_iter+0x16c/0x238 vfs_write+0x2c0/0x370 ksys_write+0x74/0x118 __arm64_sys_write+0x24/0x38 invoke_syscall+0xa8/0x118 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x54/0x370 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0 ---[ end trace 00000000000000000 ]--- 请注意，如果 detect_node_addresses 为 true，并且节点 0 或 1 无内存，则会发生同样的问题。通过在 damon_new_region（） 之前检查参数的有效性来共同修复它，如果它们无效则提早失败。
    (CVE-2026-80592)

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

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

  - RDMA/hns：修复轮询 cq 直接模式下的警告，由 ib_alloc_cq（） 分配的 CQ 始终具有comp_handler。
    尽管在直接模式下预期永远不会调用此处理程序，但仍会在重置驱动程序时调用它，从而触发以下 WARN_ONCE（）： 调用跟踪：ib_cq_completion_direct+0x38/0x60 hns_roce_cq_completion+0x54/0x90 （hns_roce_hw_v2] hns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2] hns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2] hclge_notify_roce_client+0x60/0xbc [hclge] hclge_reset_rebuild+0x48/0x34c [hclge] hclge_reset_subtask+0xcc/0xec [hclge] hclge_reset_service_task+0x80/0x160 [hclge] hclge_service_task+0x50/0x80 （hclge） process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18 （CVE-2026-80647）

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

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

  - 之前 0.38.2 的 gitoxide 无法验证传递给凭据帮助程序的 URL 值中的回车字符。攻击者可提供包含裸回车符的 URL 来注入额外的帮助程序协议字段，并造成凭据帮助程序返回攻击者指定的主机的凭据而非请求的 URL。（CVE-2026-82249）

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

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

  - powerpc/perf：修复 fsl_emb_pmu_del fsl_emb_pmu_del（） 中的抢占计数下溢 无条件调用“out：”标签处的 put_cpu_var（cpu_hw_events），但仅在“i < 0”提前返回检查后调用匹配的 get_cpu_var（）。当 event->hw.idx 为负时，函数在未采用 get_cpu_var（） 的情况下跳转到“out：”，尾随的 put_cpu_var（） 随后发出不匹配的 preempt_enable（），从而下溢preempt_count。在 CONFIG_PREEMPT=y 内核中，preempt_count将下溢并最终显示为“scheduling while atomic”缺陷。移动 put_cpu_var（） 以与 get_cpu_var（） 配对，这样 percpu 访问权限就正确地放在括号中，并且“out：”标签仅处理perf_pmu_enable。（CVE-2026-80626）

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

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

  - nodemailer 之前 9.0.1 无法将 disableFileAccess 和 disableUrlAccess 标记应用到消息级原始选项，从而允许经过认证的攻击者通过提供 path 或 href 属性来读取任意文件或执行服务器端请求伪造。攻击者可利用此漏洞，通过使用绕过预期沙盒的文件路径或 URL 构建原始消息，并在传出消息中将提取的内容传递给受攻击者控制的收件人。（CVE-2026-82659）

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

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

  - spi：spi-qpic-snand：NAND_FLASH_CMD/NAND_EXEC_CMD 执行 SET_FEATURE qcom_spi_send_cmdaddr（） 程序前写入功能值并提交描述符，使控制器立即执行命令。对于SPINAND_SET_FEATURE，要写入的值仅在第二次提交中由 qcom_spi_io_op（） 放入NAND_FLASH_FEATURES中 - 因此芯片使用该寄存器碰巧在上一个操作中保存的任何内容进行编程，并且预期值仅由 *next* SET_FEATURE应用。在 TP-Link Archer AX55 v1 （IPQ5018， ESMT F50L1G41LB） 上测量：将0x40写入配置寄存器 （0xb0） 使芯片处于 0x00，随后的 0x00 写入使其保持在 0x40
    - 每次写入都会延迟着陆一项操作。直到 v6.18 添加了 SPI-NAND OTP 支持以及 ESMT 芯片的 OTP 条目之前，这一点一直没有引起注意。spinand_otp_rw（） 启用 OTP 模式，读取然后再次禁用该模式，而 mtd_otp_nvmem_add（） 会在 MTD 注册期间执行此操作。使用差一时，禁用写入实际应用之前请求的值，因此CFG_OTP_ENABLE结束设置：芯片保持 OTP 模式，随后的每个数组读取都会返回 OTP 区域而不是数组（UBI 报告空设备），并且所有写入都因 -EIO 而失败，因为 OTP 区域受到写保护。在这个板上，这使得整个闪存无法使用，设备也无法启动。在NAND_EXEC_CMD之前，将特征值作为同一事务的一部分写入NAND_FLASH_FEATURES。并且，仅复制操作实际携带的字节 - 之前的代码取消引用单字节缓冲区上的 4 字节指针 （spinand->scratchbuf）。安装此修补程序后，闪存内容的回读与在供应商固件下采用的相同板的已知良好转储（跨分区验证 md5）位相同，并可正常写入。（CVE-2026-80712）

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

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

  - ocfs2：修复 ocfs2_remove_refcount_extent 中的越界写入 [缺陷] 断开其 refcount 树具有叶块的 refcounted 文件的链接会触发因越界写入而导致的强化错误。[原因]从 refcount 树中删除最后一个叶块后，ocfs2_remove_refcount_extent（） 会通过 &rb->rf_records 上的批量 memset 将根转换回叶模式。rf_records与rf_list处于匿名联盟中。
    rf_list.l_tree_depth 别名为 rf_records.rl_count，对于单级树而言，为 0。当rl_count等于 0 时，memset 会写入超过 16 字节声明的 rf_records 大小，强化检查器会捕获该大小。
    [修复]在将 rl_count 设置为正确值之后，将 &rb->rf_records 上的批量 memset 替换为单独的 rl_recs[] 正确边界 memset。（CVE-2026-80638）

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

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

  - hwmon：（occ） 取消注册 occ 锁定 occ_active（false） 和 occ_shutdown（） 在保留 occ->lock 时取消注册 sysfs 支持的设备。hwmon_device_unregister（） 和 sysfs_remove_group（） 可以等待活动 sysfs 回调耗尽，这些回调可能会进入 OCC 更新路径并再次尝试采取 occ->lock。这会为取消注册路径提供锁定顺序 occ->lock -> sysfs 回调漏，而回调具有相反的边缘 sysfs 回调 -> occ->lock。此问题是我们的静态分析工具发现的，然后对照当前树手动查看。接地的 PoC 保留了真正的取消注册和回调载波：occ_shutdown（） hwmon_device_unregister（） occ_show_temp_1（） occ_update_response（） Lockdep 报告了循环依赖关系，occ_shutdown（） 已经保留了 OCC 互斥体，而 hwmon_device_unregister（） 在 sysfs 端等待：警告：检测到可能的循环锁定依赖关系...（sysfs_lock） ...at：hwmon_device_unregister+0x12/0x30 [vuln_msv] ...
    （&test_occ.lock） ...at： occ_shutdown.constprop.0+0xe/0x40 [vuln_msv] occ_update_response.isra.0+0xb/0x20 [vuln_msv] occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv] *** DEADLOCK *** 使用单独的hwmon_lock序列化 hwmon 注册和删除。在此锁定下，在保留 occ->hwmon 并更新 occ->active 期间，分离 occ-hwmon 并更新 occ->active，这样并发的 OCC 状态更改仍会看到稳定状态，然后在调用 hwmon_device_unregister（） 之前终止 occ->lock。在 occ_shutdown（） 中执行 occ->lock 之前删除驱动程序 sysfs 群组，以便当保留 OCC 互斥体时无法等待耗尽驱动程序属性。此外，OCC 更新回调在停用后返回 -ENODEV，以便已通过 sysfs 主动保护的回调在拆卸分离 hwmon 设备后不会轮询硬件。（CVE-2026-80660）

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

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

  - Undertow 是 JBoss EAP 和 WildFly 中使用的灵活高性能 Web 服务器。在 Undertow 处理 WebSocket 连接的方式中发现一个缺陷。具体而言，消息缓冲区大小和会话超时等某些配置限制无法调整，默认为不受限制。这会允许远程攻击者发送大量数据或无限地维持连接，可能通过耗尽内存或其他资源导致服务器崩溃。（CVE-2026-81624）

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

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

  - 已在 valkey-io valkey 9.1.0中发现一个安全缺陷。受影响的元素是组件 Blocked-on-keys 子系统的 src/blocked.c 文件的函数 handleClientsBlockedOnKey。该操作最终触发释放后使用漏洞。攻击者可远程执行攻击。高复杂程度与此攻击相关。可利用性描述为困难。该漏洞已被公开并可被用于攻击。修补程序识别为 b2fb0e13f5b4c8c2fb63dcfc2c37a067a0d6d20b。建议应用相关补丁，以解决此问题。
    (CVE-2026-82631)

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

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

  - Ubuntu Linux - [GHSA-6v6x-387m-rj4w：网络地址集上的项目限制绕过] （CVE-2026-81499）

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

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

  - Samsung Open Source rlottie 中的不受控制递归漏洞允许包含嵌套负载的序列化数据。此问题影响 rlottie： before 8de0d9e6ca80ffef654965505981727b9fa06a51。（CVE-2026-82797）

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

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

  - 低于 8.0.5 Nodemailer 版本的 EHLO/HELO 命令中使用的传输名称选项中包含一个 SMTP 命令注入漏洞。name 参数直接串联到 SMTP 命令中，而不审查回车符和换行符，从而允许攻击者注入任意 SMTP 命令以发起电子邮件欺骗和钓鱼攻击。（CVE-2026-82853）

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

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

  - drm/vmwgfx：修复因大小而重写guest_memory_dirty位字段 vmwgfx_resource.c 中的两个站点将布尔文本分配给 res->guest_memory_size，这是一个无符号的长分配大小字段;预期目标是相邻的 res->guest_memory_dirty 位字段。分配后，该字段保留 0 或 1，而不是资源的 MOB 分配大小：- vmw_resource_release（） 写入 0 （false），而 - vmw_resource_unbind_list（） 写入 1 （true）。计算脏页范围 （vmw_bo_dirty_transfer_to_res（）） 和缓冲区分配大小 （vmw_resource_buf_alloc（）） 时，后续重新验证路径会读取guest_memory_size，从而生成通过 MOB 位图读取或写入的零长度遍历或回绕范围。原始代码的脏跟踪意图（自上次同步以来将资源标记为脏）也将丢失，因为guest_memory_dirty永远不会更新。将这两个分配重命名为 guest_memory_dirty。（CVE-2026-80702）

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

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

  - io_uring：保留 exec 之间的任务限制 每个任务的限制适用于由任务创建的所有环。一旦安装，就不应在 exec 间丢弃它们。对于已使用io_uring的任务，exec 取消路径调用 __io_uring_free（）。这会释放任务上下文和每个任务的限制，因此 exec 之后创建的环不会受到限制。将任务上下文清除拆分为 io_uring_free_tctx（），并从 exec 取消路径中使用它。保留 __io_uring_free（） 用于最终任务清除，其中上下文和限制均可释放。（CVE-2026-80713）

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

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

  - net：lwtunnel：终止 LWT 封装前的 skb 元数据 skb 元数据用于在 XDP 和 TC 之间传递信息。它位于 skb 余量中，紧邻 skb->data 之前。LWT 程序无法访问元数据的__sk_buff>data_meta伪指针。但是，LWT 封装会在前面加上外部标头，从而将 skb->data 移回元数据所在的余量。对于仍携带 XDP 元数据的 RX 发起（转发）数据包，此漏洞会以两种不同的方式出错，具体取决于封装类型：1.
    非 BPF LWT 封装（mpls、seg6、ioam6...）调用 skb_push（）/skb_pull（） 并静默覆盖余量中的元数据。2） BPF LWT xmit 调用 bpf_skb_change_head（），后者使用 skb_data_move（）。该帮助程序预期元数据紧接在 skb->data 之前。但是，由于 IP 输出路径在相邻输出构建传出 L2 标头之前运行 LWT xmit，因此对于转发的数据包，skb->data 点在 L3 标头，而 skb_mac_header（） 仍指向旧的 L2 标头。skb_data_move（） 发现元数据结尾于 skb_mac_header（），而不是在 skb->data 之前，警告并清除元数据： 警告： CPU：21 PID：454557 at include/linux/skbuff.h：4609 skb_data_move+0x47/0x90 CPU：21 UID：0 PID：454557 Comm：napi/iconduit-g 受感染：G O 6.18.21 #1 RIP：0010：skb_data_move+0x47/0x90 调用跟踪： <IRQ> bpf_skb_change_head+0xe6/0x1a0 bpf_prog_...+0x213/0x2e3 run_lwt_bpf.isra.0+0x1d3/0x360 bpf_xmit+0x46/0xe0 lwtunnel_xmit+0xa1/0xf0 ip_finish_output2+0x1e7/0x5e0 ip_output+0x63/0x100 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x9c/0x150 __napi_poll+0x2b/0x190 net_rx_action+0x40b/0x7f0 handle_softirqs+0xd2/0x270 do_softirq+0x3f/0x60 </IRQ> 至于如何修复，就会发生这种情况 - 接收到的携带元数据的数据包可以通过三种 LWT 重定向模式中的任何一种到达封装： LWTUNNEL_STATE_INPUT_REDIRECT ip6_rcv_finish dst_input lwtunnel_input LWTUNNEL_STATE_OUTPUT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output lwtunnel_output LWTUNNEL_STATE_XMIT_REDIRECT ip6_rcv_finish dst_input ip6_forward ip6_forward_finish dst_output ip6_output ip6_finish_output ip6_finish_output2 lwtunnel_xmit 每个封装都通过三个 LWT 调度帮助程序进行漏斗， 因此，在将 skb 传递给 encap op 之前，将元数据放在那里。此单一汇合点涵盖所有封装类型和所有三种重定向模式：- lwtunnel_input（）：seg6、rpl、ila、seg6_local - lwtunnel_output（）：ioam6 - lwtunnel_xmit（）：mpls、LWT BPF xmit 或者，我们可以在 TC 入口挂钩之后立即清除元数据。然而，这需要妥协。元数据将无法从 TC 出口访问（在实际到达挂钩的设置中，即路径上没有任何 L2 隧道）。
    (CVE-2026-80612)

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

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

  - 在 GDB 的 STABS 调试格式解析器中发现一个缺陷。gdb/stabsread.c 中的 read_member_functions（） 函数在用于分隔 C++ 类析构函数和非析构函数成员函数的代码中包含一个链接列表删除缺陷。此缺陷造成析构函数条目保留在主函数列表中，同时递减列表长度计数器，从而在将函数列表复制到其最终分配的数组时导致越界写入。攻击者可构建包含恶意 .stab 和 .stabstr 部分的 ELF 二进制，当用户在 GDB 中打开文件并执行任何符号检查操作（例如设置断点）时，可触发此越界写入。不需要执行次级工艺。在受控条件下，已证明这可以在 GDB 进程中实现任意命令的执行。（CVE-2026-13732）

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

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

  - Ubuntu Linux - 安全更新 （CVE-2026-81496）

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

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

  - Elixir 标准库中的不受控制递归漏洞可让攻击者控制传递到 inspect/1、List.to_string/1 或 List.to_charlist/1 的列表，耗尽 BEAM 节点的内存。
    Inspect.List 在 lib/elixir/lib/inspect.ex 中的 charlist 分支使用 List.ascii_printable？/2 将列表分类为 charlist，其仅检查第一个 :p rintable_limit（默认为 4096）元素，然后对整个术语调用 IO.chardata_to_string/1。可打印前缀超出该限制但包含后面的非代码点元素（原子、超出范围的整数或错误的末尾）的列表因此被错误分类，并且转换会引发 ArgumentError。该转换在 List.to_string/1 内部运行，其 rescue 子句通过插值 inspect（list） 构建其消息，从而重新进入同一分支并再次引发。嵌套检查是一个要引发的参数，因此递归不在尾部位置，并且保留了每个级别：当每个周期重新遍历列表时，进程堆栈会单调增长，直到进程被max_heap_size终止，或者默认情况下，节点耗尽内存。
    List.to_charlist/1 具有相同的救援形状。低于可打印限制，内部 inspect/1 会发现其计数器中的无效元素，并以普通括号形式呈现列表，因此会引发单个 ArgumentError 并且不会发生递归。此问题影响 elixir：从 1.15.0-rc.0 到 1.18.5之前 、 从 1.19.0-rc.0 到 1.19.6和 之前的 1.20.0-rc.0 到 1.20.4。（CVE-2026-75758）

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

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

  - 之前的 Nodemailer 8.0.4 容易遭受通过未清理的 envelope.size 参数进行的 SMTP 命令注入攻击。当应用程序将自定义信封对象与包含 CRLF 字符的 size 属性传递到 sendMail（） 时，该值未经审查即被串联到 SMTP MAIL FROM 命令中（作为 SIZE=...），从而允许注入任意 SMTP 命令（例如 RCPT TO）以静默方式添加受攻击者控制的收件人。利用此漏洞要求应用程序将信封大小暴露给攻击者控制的输入，因为 Nodemailer 未包含在默认的自动构造信封中。
    (CVE-2026-82854)

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

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

  - iommufd/viommu：释放vdevice_size错误路径上的 igroup 锁定 iommufd_vdevice_alloc_ioctl（） 采用 idev->igroup->lock，然后根据核心结构大小通过WARN_ON_ONCE验证驱动程序的vdevice_size。若失败，防护会跳至低于 out_unlock_igroup 的 out_put_idev，因此会跳过 mutex_unlock（），保留 igroup 锁定并死锁该组上的下一个 vDEVICE 操作。
    请跳转到 out_unlock_igroup。（CVE-2026-80687）

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

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

  - 已修复 Linux 内核中的下列漏洞：wifi: mt76: mt7996: Fix NULL pointer dereference in mt7996_init_tx_queues() When MT76_NPU and CONFIG_NET_MEDIATEK_SOC_WED are enabled and mt76 detects properly the Airoha NPU SoC, mt7996_init_tx_queues() will dereference a NULL WED pointer. Fix the issue by always passing the WED pointer from mt7996_dma_init(). (CVE-2026-80632)

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

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

  - 当 Apache Shiro 与 Jakarta EE 集成模块一起使用时，低权限用户可构建 HTTP 请求，导致服务器向攻击者控制的 URL 初始化连接，并传输攻击者控制的数据。此漏洞仅影响使用 Jakarta EE 集成模块的部署中的 Apache Shiro 版本2.x3.0.0。缓解：升级到版本或更高版本 3.0.1 ，可修复此问题。 + 或者，您可以设置“org.apache.shiro.form-resubmit-host”（字符串）和“org.apache.shiro.form-resubmit-port”（整数）系统属性，以限制 Shiro 在重新提交表单时将连接的主机和端口。（CVE-2026-58301）

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

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

  - MongoDB Server 中的一个问题可允许具有有效客户端证书和相应用户帐户的一方使用基于证书的认证方法进行认证，即使管理员已将服务器配置为将认证限制于其他机制时也是如此。这可允许通过管理员打算禁用的方法进行认证。（CVE-2026-18703）

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

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

  - 已修复 Linux 内核中的下列漏洞：riscv/mm: use physical alignment for vmemmap_start_pfn RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to VMEMMAP_ADDR_ALIGN.
    That alignment must therefore be expressed in the physical-address domain. Commit 476849b0fba4 (riscv/mm:
    align vmemmap to maximal folio size) attempted to account for the maximal folio alignment by feeding MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN. However, MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage, whereas VMEMMAP_ADDR_ALIGN is used to align a physical address. The mask-based compound_info encoding requires pfn_to_page(0) to be naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN.
    Commit 9f94db4c7eaa (mm/sparse: check memmap alignment for compound_info_has_mask()) added a check for that requirement and exposed the unit mismatch on systems such as QEMU virt, where the DRAM base is not aligned to MAX_FOLIO_NR_PAGES * PAGE_SIZE. Here is the log: [ 0.000000][ C0] ------------[ cut here]------------ [ 0.000000][ C0] WARNING: mm/sparse.c:365 at sparse_init+0x58a/0x6fe, CPU#0: swapper/0 [0.000000][ C0] Modules linked in: [ 0.000000][ C0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.2.0-rc3-g1d8304bdd65f #2 PREEMPT [ 0.000000][ C0] Hardware name: riscv-virtio,qemu (DT) [ 0.000000][ C0] epc : sparse_init+0x58a/0x6fe [ 0.000000][ C0] ra : sparse_init+0x58a/0x6fe [ 0.000000][ C0] epc :
    ffffffff86851c88 ra : ffffffff86851c88 sp : ffffffff88807a30 [ 0.000000][ C0] gp : ffffffff8a3bf240 tp :
    ffffffff88842080 t0 : ff600000ffab6000 [ 0.000000][ C0] t1 : 000000017fab6000 t2 : 65203a6573726363 s0 :
    ffffffff88807bc0 [ 0.000000][ C0] s1 : 000000000e000000 a0 : 0000000000000007 a1 : 0000000000000000 [0.000000][ C0] a2 : 0000000000000002 a3 : ffffffff86851c88 a4 : 0000000000000000 [ 0.000000][ C0] a5 :
    ffffffff88843080 a6 : 0000000000000003 a7 : 0000000000000000 [ 0.000000][ C0] s2 : ff60000000000000 s3 :
    0040000000000000 s4 : 0004000000000000 [ 0.000000][ C0] s5 : ffffffff8a4d92e0 s6 : ff600000ffab55e0 s7 :
    ffffffff88384d00 [ 0.000000][ C0] s8 : 0000000000000003 s9 : ffffffff88384cc1 s10: ffffffff88384cc0 [0.000000][ C0] s11: ffffffff8a4daae0 t3 : ffffffff915e8b20 t4 : ffffffff915e8b20 [ 0.000000][ C0] t5 :
    ffffffff915e8b20 t6 : ffffffff915e8bc8 ssp : 0000000000000000 [ 0.000000][ C0] status: 0000000200000100 badaddr: ffffffff86851c88 cause: 0000000000000003 [ 0.000000][ C0] [<ffffffff86851c88>] sparse_init+0x58a/0x6fe [ 0.000000][ C0] [<ffffffff8683d396>] mm_core_init_early+0x116/0x1e30 [ 0.000000][C0] [<ffffffff86801edc>] start_kernel+0xd2/0x848 Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment before using it in VMEMMAP_ADDR_ALIGN. This keeps the existing round_down() logic while making the resulting vmemmap base satisfy the mask-alignment requirement. (CVE-2026-80682)

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

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

  - riscv：从 vec_check_unaligned_access_speed_all_cpus 中丢弃 __init 此函数在 kthread 内运行，不必在系统完成引导和 free_initmem（） 取消映射 .init.text 部分之前完成。
    此函数会调用 SBI 以探测未对齐的访问速度，如果由于某些原因速度缓慢（例如，某些调试打印已添加至 SBI），则 kthread 此时仍可以运行，并可在尝试从已释放区域提取时导致指令页面错误。[ 25.642087] 无法处理虚拟地址 ffffffff80a04ef8 上的内核分页请求 [ 25.646694] 当前 vec_check_unali pgtable：4K 页面大小，48 位 VA， pgdp=0x00004000316e9000 [ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401， p4d=000010004be7e401， pud=000010004be7e001[ pmd=000010000c3000e325.661244] Oops [#1] 25.662997[ ] 模块链接： [ 25.665357] CPU：3 UID：0 PID：42 通信：vec_check_unali 未受感染 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY [ 25.674669] 硬件名称：Tenstorrent Blackhole （DT） [ 25.678545] EPC：vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.683458] RA：
    vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.688372] EPC：ffffffff80a04ef8 RA：
    ffffffff80a04ef8 sp： ffff8f8000203e20 [ 25.693874] GP： ffffffff814dc168 tp： ffffaf8001ad9900 t0：
    0000000000000000 [ 25.699401] t1： ffffffffffff0 t2： ffffaf8001ad9a10 s0： ffff8f8000203e30 [25.704912] s1： ffffaf80018dc780 a0： 0000000000000000 a1： 0000000000000002 [ 25.710407] a2：
    000000000000001f0 A3： 0000000000000018 A4： 00000000000000000 [ 25.715917] A5： 00000000000000000 A6：
    ffffaf8001c03d98 a7： ffffaf8001c03e30 [ 25.721419] s2： ffff8f8000023c98 s3： ffffaf8001aa1240 s4：
    ffffffff80a04ee0 [ 25.726937] s5 ： 00000000000000000 s6 ： 00000000000000000 s7 ： 0000000000000000 [25.732450] s8 ： 00000000000000000 s9 ： 00000000000000000 s10： 0000000000000000 [ 25.737944] s11：
    0000000000000000 T3： 0000000000000002 T4： 0000000000000402 [ 25.743481] T5： 0000000000000040 T6：
    0000000000000004 ssp：0000000000000000 [ 25.749024] status： 0000000200000120 badaddr： ffffffff80a04ef8 原因：000000000000000c [ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.760964]<ffffffff80047a10> [] kthread+0xd8/0xfc [25.764660] []<ffffffff80010c48> ret_from_fork_kernel+0x18/0x1c4 [ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18 [ 25.774018] 代码：cccc cccc （cccc） 从签名中删除 __init，以免发生此情况。（CVE-2026-80688）

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

ID	名称	严重性
341991	Linux Distros 未修补的漏洞：CVE-2026-18701	high
341990	Linux Distros 未修补的漏洞：CVE-2026-80610	medium
341989	Linux Distros 未修补的漏洞：CVE-2026-80673	critical
341988	Linux Distros 未修补的漏洞：CVE-2026-80594	medium
341987	Linux Distros 未修补的漏洞：CVE-2026-80621	medium
341986	Linux Distros 未修补的漏洞：CVE-2026-80608	high
341985	Linux Distros 未修补的漏洞：CVE-2026-82662	high
341984	Linux Distros 未修补的漏洞：CVE-2026-18706	high
341982	Linux Distros 未修补的漏洞：CVE-2026-82660	medium
341981	Linux Distros 未修补的漏洞：CVE-2024-58377	medium
341980	Linux Distros 未修补的漏洞：CVE-2026-80641	high
341979	Linux Distros 未修补的漏洞：CVE-2026-80719	medium
341978	Linux Distros 未修补的漏洞：CVE-2026-18705	high
341977	Linux Distros 未修补的漏洞：CVE-2026-80597	medium
341976	Linux Distros 未修补的漏洞：CVE-2026-18700	medium
341975	Linux Distros 未修补的漏洞：CVE-2026-80661	high
341974	Linux Distros 未修补的漏洞：CVE-2026-81497	critical
341973	Linux Distros 未修补的漏洞：CVE-2026-80620	medium
341972	Linux Distros 未修补的漏洞：CVE-2026-80599	high
341971	Linux Distros 未修补的漏洞：CVE-2026-82821	medium
341970	Linux Distros 未修补的漏洞：CVE-2026-80595	medium
341969	Linux Distros 未修补的漏洞：CVE-2026-80646	high
341968	Linux Distros 未修补的漏洞：CVE-2026-80666	medium
341967	Linux Distros 未修补的漏洞：CVE-2026-83596	high
341966	Linux Distros 未修补的漏洞：CVE-2026-80592	high
341965	Linux Distros 未修补的漏洞：CVE-2026-80647	medium
341964	Linux Distros 未修补的漏洞：CVE-2026-82249	low
341963	Linux Distros 未修补的漏洞：CVE-2026-80626	high
341961	Linux Distros 未修补的漏洞：CVE-2026-82659	high
341960	Linux Distros 未修补的漏洞：CVE-2026-80712	high
341959	Linux Distros 未修补的漏洞：CVE-2026-80638	high
341958	Linux Distros 未修补的漏洞：CVE-2026-80660	medium
341957	Linux Distros 未修补的漏洞：CVE-2026-81624	high
341956	Linux Distros 未修补的漏洞：CVE-2026-82631	low
341955	Linux Distros 未修补的漏洞：CVE-2026-81499	critical
341954	Linux Distros 未修补的漏洞：CVE-2026-82797	medium
341953	Linux Distros 未修补的漏洞：CVE-2026-82853	medium
341952	Linux Distros 未修补的漏洞：CVE-2026-80702	high
341951	Linux Distros 未修补的漏洞：CVE-2026-80713	high
341950	Linux Distros 未修补的漏洞：CVE-2026-80612	critical
341949	Linux Distros 未修补的漏洞：CVE-2026-13732	high
341947	Linux Distros 未修补的漏洞：CVE-2026-81496	critical
341946	Linux Distros 未修补的漏洞：CVE-2026-75758	medium
341945	Linux Distros 未修补的漏洞：CVE-2026-82854	critical
341944	Linux Distros 未修补的漏洞：CVE-2026-80687	medium
341943	Linux Distros 未修补的漏洞：CVE-2026-80632	medium
341942	Linux Distros 未修补的漏洞：CVE-2026-58301	medium
341941	Linux Distros 未修补的漏洞：CVE-2026-18703	low
341940	Linux Distros 未修补的漏洞：CVE-2026-80682	high
341939	Linux Distros 未修补的漏洞：CVE-2026-80688	medium

检测

Nessus 的 Misc. 系列

high

medium

critical

medium

medium

high

high

high

medium

medium

high

medium

high

medium

medium

high

critical

medium

high

medium

medium

high

medium

high

high

medium

low

high

high

high

high

medium

high

low

critical

medium

medium

high

high

critical

high

critical

medium

critical

medium

medium

medium

low

high

medium