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

  - drm/atmel-hlcdc：修复 atomic_destroy_state 回调造成的内存泄漏 几次提交后，slab 内存会增加。某些drm_crtc_commit对象未释放。atomic_destroy_state 回调仅放置帧缓冲区。使用 __drm_atomic_helper_plane_destroy_state（） 函数将不再需要的所有对象放入。已在使用图形应用程序或使用 kmemleak 数小时后发现：
    未引用的对象0xc63a6580（大小 64）：comm egt_basic、pid 171、jiffies 4294940784 hex 转储（前 32 字节）：40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:.8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e：......e:..e:.回溯 （CRC c25aa925）：kmemleak_alloc+0x34/0x3c
    __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 （CVE-2026-43269）

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

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

  - soc：ti：pruss：修复 pruss_clk_mux_setup（） 中的双重释放 在 pruss_clk_mux_setup（） 中，devm_add_action_or_reset（） 间接调用 pruss_of_free_clk_provider（），后者会在错误路径上调用 of_node_put（clk_mux_np）。但是，在 devm_add_action_or_reset（） 返回后，of_node_put（clk_mux_np） 会再次被调用，从而导致双重释放。通过直接返回进行修复，以避免重复的 of_node_put（）。（CVE-2026-43196）

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

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

  - net：usb：kaweth：删除 kaweth_set_rx_mode kaweth_set_rx_mode（）（）（ndo_set_rx_mode 回调）中的 TX 队列操纵，会调用 netif_stop_queue（） 和 netif_wake_queue（）。这些是与 RX 组播配置无关的 TX 队列流控制功能。过早的 netif_wake_queue（） 可在 tx_urb 仍在运行时重新启用 TX，从而导致同一 URB 上的双重 usb_submit_urb（）： kaweth_start_xmit（） {netif_stop_queue（）; usb_submit_urb（kaweth->tx_urb）; } kaweth_set_rx_mode（） { netif_stop_queue（）;
    netif_wake_queue（）;在 URB 完成前唤醒 TX 队列 } kaweth_start_xmit（） { netif_stop_queue（）;
    usb_submit_urb（kaweth->tx_urb）;活动时提交 URB } 这会在 usb_submit_urb（） 中触发 WARN： 活动时提交 这是在 rtl8150 中由下列问题修复的类似缺陷： - 提交 958baf5eaee3（net：usb： 删除 rtl8150_set_multicast 中的破坏性netif_wake_queue）。此外，kaweth_set_rx_mode（） 在功能上已经被破坏，真正的set_rx_mode操作由 kaweth_async_set_rx_mode（） 执行，这反过来又不是仅在 ndo_open（） 时的 no-op。（CVE-2026-43180）

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

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

  - media：v4l2-async：修复查找匹配之后步骤的错误处理 一旦发现异步连接与 fwnode 匹配，便可注册子设备（如果尚未注册），调用其绑定操作，创建辅助链接，将异步连接添加到子设备的连接列表，并从全局等待连接列表中删除。此外，系统会搜索子设备可能的自身通知程序，寻找可能的其他匹配项目。修复以下特定问题：- 如果 v4l2_async_match_notify（） 在子通知程序处理之前失败，则异步连接会解除绑定，并且其条目会从子设备的异步连接列表中删除。后一部分也是在 v4l2_async_match_notify（） 中完成的。- 异步连接的 sd 字段仅在 v4l2_async_match_notify（） 中创建辅助链接之后设置。但是，它在 v4l2_async_unbind_subdev_one（） 中被取消引用，后者在 v4l2_async_match_notify（） 失败的错误路径中调用。（CVE-2026-43189）

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

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

  - ASoC：SDCA：修复 IRQ 清理中的错误 IRQ 可使用 devm_request_threaded_irq（） 通过组件探头的 sdca_irq_populate（） 启用，但这意味着即使拆解声卡，IRQ 仍可持续存在。
    部分 IRQ 处理程序会存储对卡和 kcontrols 的引用，但随后可能会失败。[1] 中解释了崩溃的一些细节。通常不建议在总线探测之外使用 devm，因此代码已更新为不使用 devm。IRQ 请求不会移动到总线探测时间，因为这会使将snd_soc_component传递到 IRQ 变得非常笨拙，并且一旦组件可用，将需要第二步，因此此时只需注册 IRQ 会更简单，即使这需要一些手动清理。（CVE-2026-43095）

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

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

  - ring-buffer：修复可能取消引用未初始化指针的问题 rb_meta_validate_events（） 中存在一个在函数开始时未初始化的指针head_page。如果在阅读器页面验证期间失败，则可取消引用此指针。在这种情况下，控件会传递到无效标签，指针会在循环中取消引用。若要修复此问题，请在调用 rb_validate_buffer 之前初始化 orig_head 和 head_page。由 Linux Verification Center (linuxtesting.org) 和 SVACE 发现。(CVE-2026-43272)

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

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

  - ksmbd：修复 smb_direct_prepare_negotiation（） 中的符号缺陷 smb_direct_prepare_negotiation（） 在计算 min_t（int， ...） 之前，将未签名的 __u32 值从 sp->max_recv_size 和 req->preferred_send_size 转换为已签名的 int。恶意提供的 0x80000000 preferred_send_size将返回小于 max_recv_size，然后用于设置下一条消息的最大允许接收大小。然后，通过发送具有大值（>1420 字节）的第二条消息，攻击者可实现堆缓冲区溢出。此补丁将 min_t（int， ...） 替换为 min_t（u32） （CVE-2026-43185）

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

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

  - most：core：修复most_register_interface错误路径中的资源泄漏 如果函数 most_register_interface（） 提早失败（在注册设备之前），则不会正确释放资源。在这些情况下，它会立即返回错误代码，从而泄漏为接口分配的内存。通过 device_initialize（） 及在所有错误路径中调用 put_device（），提早初始化设备，即可修复此问题。预期 most_register_interface（） 在出错时调用 put_device（），从而释放调用程序中分配的资源。put_device（） 根据调用程序调用 release_mdev（） 或 dim2_release（）。切换为使用 device_add（） 而不是 device_register（） 来处理拆分初始化。（CVE-2025-71272）

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

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

  - media：i2c/tw9903：修复 tw9903_probe（） 中潜在的内存泄漏 在 tw9903_probe（） 的其中一个错误路径中，未释放 v4l2_ctrl_handler_init（） 和 v4l2_ctrl_new_std（） 中分配的内存。通过在该错误路径中的处理程序上调用 v4l2_ctrl_handler_free（） 来修复此问题。（CVE-2026-43218）

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

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

  - wifi：rtw89：修复信标跟踪中潜在的零信标间隔 在模糊测试期间，发现 bss_conf->beacon_int 可能为零，从而可在后续计算中导致除以零错误。如果间隔为零，则将默认值设置为 100 TU 以确保稳定性。（CVE-2026-43267）

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

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

  - ASoC：SOF：ipc4-topology：修正字节控件的分配大小 字节控件的 scontrol->ipc_control_data 背后的数据大小为： [1] sizeof（struct sof_ipc4_control_data） + // 仅内核 struct [2] sizeof（struct sof_abi_hdr）） + 负载 max_size指定 [2] 的大小，它来自拓扑结构。更改函数以将此纳入考虑，并在 scontrol->ipc_control_data 后面分配足够数量的内存。通过更改，我们将分配 [1] 多的内存以能够容纳完整大小的数据。（CVE-2025-71286）

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

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

  - net：ipa：修复 IPA v5.0+ 的GENERIC_CMD寄存器字段掩码 修复字段掩码以匹配下游 GSI （GSI_V3_0_EE_n_GSI_EE_GENERIC_CMD_*） 中记录的硬件布局。值得注意的是，这修复了我在 IPA 运行时尝试向 MPSS remoteproc 发送停止时看到的警告。（CVE-2026-43081）

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

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

  - drm/atmel-hlcdc：修复释放后对 drm_crtc_commit 的释放后使用 atmel_hlcdc_plane_atomic_duplicate_state（） 回调在未正确复制drm_plane_state的情况下复制atmel_hlcdc_plane状态结构。特别是，state->commit 仍然设置为旧状态提交，这可在下一个 drm_atomic_commit（） 调用中导致释放后使用。通过调用
    __drm_atomic_helper_duplicate_plane_state（），可正确克隆基础drm_plane_state（包括 ->提交指针）。在仍连接另一个 DRM 客户端（例如 fbdev）时关闭并重新打开设备节点时，可以看到这种情况：
    ============================================================================= 缺陷 kmalloc-64（未受感染）：毒药覆盖 ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836。首个字节0x6a而非0x6b 修复 kmalloc-64：恢复中毒 0xc611b344-0xc611b344=0x6b 在 drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 已释放在 drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 PID=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200（workingset|zone=0） 对象 0xc611b340 @offset=832 fp=0xc611b7c0 （CVE-2026-43236）

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

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

  - ASoC：qcom：q6asm：终止已关闭数据流的 DSP 响应“提交 a354f030dbce （ASoC：qcom：q6asm：
    处理关闭后的响应）'尝试忽略流关闭后到达的 DSP 响应。但是，这些响应仍会被处理，从而导致锁定。通过无条件丢弃与已关闭的数据流关联的所有 DSP 响应修复此问题。（CVE-2026-43204）

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

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

  - smb：客户端：防止 ->query_interfaces（） 中的争用 两个查询界面可能同时尝试更新接口。通过检查和更新 iface_lock 下的iface_last_update防止这种情况发生。（CVE-2026-43239）

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

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

  - arm64：添加对 Spectre-BHB 缓解措施的支持 TSV110 该 TSV110 处理器容易遭受 Spectre-BHB（分支历史记录缓冲区）攻击，可利用该攻击通过分支预测边信道泄漏信息。此提交会将 的 MIDR TSV110 添加到软件缓解列表中。（CVE-2026-43261）

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

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

  - ntfs：->d_compare（） 不得阻断 ...所以不要在那里使用 __getname（）。将其（和 ntfs_d_hash（），趁我们这样做时）切换到 kmalloc（PATH_MAX， GFP_NOWAIT）。是的，ntfs_d_hash（） 几乎可以肯定可以进行较小的分配，但让 ntfs 人员来处理这个问题 - 暂时保持分配大小不变。停止滥用 ntfs 中的names_cachep，句点 - 其中那个东西的各种用法与路径名无关;只需使用 k[mz]alloc（） 即可完成。目前让我们保持大小不变，但 AFAICS 实际上没有一个用户想要PATH_MAX。 （CVE-2026-43245）

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

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

  - media：tegra-video：修复 __tegra_channel_try_format（） 中出现的内存泄漏 由
    不再需要 __v4l2_subdev_state_alloc（） 时，必须通过 __v4l2_subdev_state_free（） 将其释放。在
    __tegra_channel_try_format（） 中，v4l2_subdev_call（） 失败后会直接返回两个错误路径，且不会释放分配的“sd_state”对象。这违反了要求，导致内存泄漏。通过引入清理标签并在错误路径中使用 goto 语句来修复此问题，以确保
    总是在函数返回之前调用 __v4l2_subdev_state_free（）。（CVE-2026-43162）

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

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

  - net：消耗 GSO 帧的 xmit 错误 udpgro_frglist.sh 和 udpgro_bench.sh 是目前 NIPA 中最不稳定的测试。它们会以完全相同的方式失败，TCP GRO 测试偶尔会停止，且测试会在 10 分钟后终止。这些测试使用 veth 来模拟 GRO。它们附加一个普通（返回XDP_PASS;XDP 程序强制关闭 TSO 并打开 NAPI。深入研究故障模式，我们可以看到连接在爆发性掉线后完全卡住。发送方的snd_nxt序列号为 N [1]，但接收方声称已收到（rcv_nxt）最多 N + 3 * MSS [2]。最后一块拼图是发送方 rtx 队列不是空的（假设 rtx 队列中的块位于序列号 N - 4 * MSS [3]）。在这种状态下，发送方发送来自 rtx 队列的重传具有单一段，序列号为 N-4*MSS：N-3*MSS [3]。接收方看到它并以 ACK 一直响应，最高可达 N + 3 * MSS [2]。
    但是发送者会拒绝此 ack 作为TCP_ACK_UNSENT_DATA，因为它不记得曾经将数据发送到那么远的地方 [1]。我们被困住了。根本原因是 xmit 返回代码的混乱。veth 在无法 xmit 帧时返回错误。我们最终会遇到这样的损失事件：
    ------------------------------------------------- |GSO超级车架1 |GSO超级车架2 | |-----------------------------------------------| |赛格 |赛格 |赛格 |赛格 |赛格 |赛格 |赛格 |赛格 | |1 |2 |3 |4 |5 |6 |7 |8 |------------------------------------------------- x ok ok | <ok>ok ok ok \ <x> \ snd_nxt x 表示 veth 丢失的数据包，ok 表示它通过了。由于 veth 在此测试中禁用了 TSO，所以它可以看到各个段。段 1 位于重传队列中，将被重新发送。那么，为什么发送方没有前进snd_nxt即使它显然已经发送到第 8 段呢？tcp_write_xmit（） 会将来自核心的返回代码解释为表示根本未发送数据。由于 TCP 处理的是 GSO 超帧，而不是单个段，因此问题的关键在于单个段的丢失可解释为全部丢失。TCP 只看到 GSO 帧最后一段的最后一个返回代码（在上图中的<>括号中）。当然，要使问题发生，我们需要一个没有 Qdisc 的设置或设备。
    否则，Qdisc 层会完全断开协议层与设备错误的连接。我们有多种方法可以解决此问题。1） 使 veth 在丢失数据包时不返回错误。虽然我认为这是我们过去所做的，但问题不断重复出现，调试起来很烦人。打痣的游戏并不好。2） 修复该死的返回代码我们在文档中只讨论NETDEV_TX_OK和NETDEV_TX_BUSY，所以也许我们应该将 ndo_start_xmit（） 的返回代码设为布尔值。我最喜欢它，但也许一些古老的、不是真正的网络协议会受到影响。3） 使 TCP 忽略错误我并不完全清楚 TCP 从解释 ip_queue_xmit（） 的结果中获得了什么好处？具体来说，一旦建立了连接并且我们正在推送数据 - 数据包丢失只是数据包丢失吗？4） 此补丁 忽略 Qdisc-less+GSO 情况中的 rc，因为它不可靠。在TCQ_F_CAN_BYPASS的情况下，我们已始终返回 OK。在无 Qdisc 的情况下，我们保守一点，仅掩盖 GSO 错误。此路径由非 IP 网络（如 CAN、MCTP 等）采用，因此我们可以回归一些古老的事物。这是最简单的，但也可能是最黑客的修复？Eric 过去曾提出过类似的修复方案，但从未提交，因为原始报告者使用 OOT 驱动程序且未提供反馈（参见链接）。（CVE-2026-43194）

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

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

  - ALSA：usb-audio：在静默时为 OOB 写入添加健全性检查。在实际回放之前，在隐式 fb 模式下将回放 URB 数据包静默时，我们盲目地假设接收到的数据包符合缓冲区大小。但当捕获流中的设置与回放流不同时（例如，由于 USB 核心限制为最大数据包大小），这种不一致可能导致对缓冲区的 OOB 写入，从而导致崩溃。若要解决此问题，请在 prepare_silent_urb（） 添加传输缓冲区大小的健全性检查，并在收到的数据溢出时停止数据复制。此外，也从那里正确地报告传输错误。请注意，这不会修复回放错误本身的根源，而这仅涉及内核 Oops。（CVE-2026-43279）

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

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

  - Bluetooth：L2CAP：修复缺少的 L2CAP_LE_CONN_REQ 密钥大小检查 这增加了在接收 L2CAP/LE/CFC/BV-15-C 所需的L2CAP_LE_CONN_REQ时对加密密钥大小的检查（预期L2CAP_CR_LE_BAD_KEY_SIZE）。（CVE-2026-43134）

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

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

  - ceph：在 ceph_zero_partial_object（） 中提供快照上下文 ceph_zero_partial_object 函数缺少其 OSD 写入操作的正确快照上下文，这可导致快照中的数据不一致。复制品：../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/cachesmd5sum /mnt/mycephfs/.snap/snap1/foo # 获取不同的 md5sum！！（CVE-2026-43273）

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

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

  - cifs：修复 tcon 字段的锁定使用情况 过去我们使用该cifs_tcp_ses_lock来保护许多对象，而不仅仅是服务器、ses 或 tcon 列表。我们后来引入了 srv_lock、ses_lock 和 tc_lock 来保护相应结构中的字段。这样做是为了提供更精细的保护并避免不必要的序列化。仍有一些 cifs_tcp_ses_lock 用于提供 tcon 字段。在此修补程序中，我已将它们替换为 tc_lock。（CVE-2026-43215）

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

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

  - xfs：删除空时的 attr 叶自由映射条目 返回提交 2a2b5932db6758 （xfs：修复 attr 叶标头 freemap.size 下溢），Brian Foster 发现，减去条目数组扩展所消耗的空间时，xattr 条目数组结尾的小自由映射可能出现大小下溢。只有三个自由映射条目，这意味着它不是叶块中所有可用空间的完整索引。此代码可能会留下具有非零基数的零长度 freemap 条目。后续的 setxattr 操作可以增加库，直到它与另一个自由映射条目重叠。这本身不是问题，因为 _leaf_add 中查找可用空间的代码会忽略任何大小为零的自由映射条目。但是，_leaf_add 的自由映射更新代码中还有另一个缺陷，即无法更新从刚附加到数组的 xattr 条目中开始的自由映射条目。这可能导致 freemap 包含两个具有相同基数但大小不同的条目（上推条目为 0，实际跟踪可用空间的条目为非零）。然后，后续_leaf_add可在条目数组顶部分配 xattr 名称值条目，从而导致数据丢失。但修复这个问题是以后的事。目前，通过将任何大小为零的自由映射条目的基础清零来消除混淆的可能性。由于自由映射并非可用空间的完整索引，因此随后未能找到新 xattr 的任何可用空间将触发区块压缩，从而重新生成自由映射。看起来这个错误在代码库中已经存在了很长时间。（CVE-2026-43187）

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

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

  - mfd：core：添加围绕“mfd_of_node_list”的锁定 在没有某种互斥的情况下，操控内核中的列表并不安全。每当访问/修改“mfd_of_node_list”时添加互斥体，以防止可能的崩溃。（CVE-2026-43143）

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

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

  - 已修复 Linux 内核中的下列漏洞：bridge: guard local VLAN-0 FDB helpers against NULL vlan group When CONFIG_BRIDGE_VLAN_FILTERING is not set, br_vlan_group() and nbp_vlan_group() return NULL (br_private.h stub definitions). The BR_BOOLOPT_FDB_LOCAL_VLAN_0 toggle code is compiled unconditionally and reaches br_fdb_delete_locals_per_vlan_port() and br_fdb_insert_locals_per_vlan_port(), where the NULL vlan group pointer is dereferenced via list_for_each_entry(v, &vg->vlan_list, vlist). The observed crash is in the delete path, triggered when creating a bridge with IFLA_BR_MULTI_BOOLOPT containing BR_BOOLOPT_FDB_LOCAL_VLAN_0 via RTM_NEWLINK. The insert helper has the same bug pattern. Oops:
    general protection fault, probably for non-canonical address 0xdffffc0000000056: 0000 [#1] KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000002b0-0x00000000000002b7] RIP:
    0010:br_fdb_delete_locals_per_vlan+0x2b9/0x310 Call Trace: br_fdb_toggle_local_vlan_0+0x452/0x4c0 br_toggle_fdb_local_vlan_0+0x31/0x80 net/bridge/br.c:276 br_boolopt_toggle net/bridge/br.c:313 br_boolopt_multi_toggle net/bridge/br.c:364 br_changelink net/bridge/br_netlink.c:1542 br_dev_newlink net/bridge/br_netlink.c:1575 Add NULL checks for the vlan group pointer in both helpers, returning early when there are no VLANs to iterate. This matches the existing pattern used by other bridge FDB functions such as br_fdb_add() and br_fdb_delete(). (CVE-2026-43100)

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

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

  - fbdev：of：display_timing：修复 of_get_display_timings（） 中的 refcount 泄漏 of_parse_phandle（） 返回 refcount 递增的device_node，该存储在“entry”中，然后复制到“native_mode”。当第 184 或 192 行的错误路径跳至“entryfail”时，native_mode 的 refcount 未递减，从而造成 refcount 泄漏。通过将转至目标从“entryfail”更改为“timingfail”来修复此问题，这将在清除前正确调用 of_node_put（native_mode）。（CVE-2026-43264）

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

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

  - clocksource/drivers/sh_tmu：探测之后始终让设备保持运行状态 TMU 设备可用作时钟源和时钟事件提供程序。驱动程序尝试变得聪明并打开和关闭自己的电源，并在时钟不运行时启用和禁用其时钟。如果将 TMU 用作早期平台设备，则此行为会略有改变，其中设备在探测后保持通电状态，但时钟仍会在运行时启用和禁用。这已经奏效了很长时间，但 PREEMPT_RT 和 PROVE_LOCKING 中的最近改进凸显了一个问题。当 TMU 将自己注册为 clockevent 提供程序 clockevents_register_device（） 时，它需要在内部使用原始自旋锁，因为这是 clockevent 框架与 TMU 驱动程序交互的上下文。但是，在持有原始自旋锁的上下文中，TMU 驱动程序无法通过调用 pm_runtime_*（） 和 clk_*（） 来真正管理其电源状态或时钟，因为这些调用最终会进入其他使用常规自旋锁来控制电源和时钟的平台驱动程序。这种旋转锁上下文组合会触发 lockdep 警告。============================= [ BUG：
    无效的等待上下文 ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 未受感染
    ----------------------------- swapper/0/0 正在尝试锁定：ffff000008c9e180 （&dev->power.lock）{-...}-{3:3}， at： __pm_runtime_resume+0x38/0x88可能有助于我们调试此漏洞的其他信息： context-{5:5} 1 lock held by swapper/0/0： ccree e6601000.crypto： ARM CryptoCell 630P 驱动程序： HW 版本 0xAF400001/0xDCC63000，驱动程序版本 5.0 #0： ffff8000817ec298 ccree e6601000.crypto： ARM ccree 设备初始化 （tick_broadcast_lock）{-...}-{2:2}， at： __tick_broadcast_oneshot_control+0xa4/0x3a8 堆栈回溯： CPU： 0 UID： 0 PID： 0 通信： swapper/0 未受感染 6.18.0-arm64-renesas-09926-gee959e7c5e34#1 PREEMPT 硬件名称：基于 r8a77965 （DT） 的 Renesas Salvator-X 第二版主板调用跟踪：
    show_stack+0x14/0x1c （C） dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230
    __primary_switched+0x88/0x90 对于非PREEMPT_RT版本，这实际上不是问题，但对于普通旋转锁可以休眠的PREEMPT_RT版本，这可能是一个问题。请小心，探测后始终保持电源和时钟运行。（CVE-2026-43227）

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

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

  - PCI：修复 pci_slot_trylock（） 错误处理提交 a4e772898f8b（PCI：向 pci_bus_lock（）） 添加缺少的桥接锁定）将桥接设备的 pci_dev_trylock（） 委派给 pci_slot_trylock（） 中的 pci_bus_trylock（），但忘记在 pci_bus_trylock（） 失败时删除相应的 pci_dev_unlock（）。在 a4e772898f8b 之前，代码为：if （！pci_dev_trylock（dev）） /* <- 锁定桥接设备 */ 前往解锁;if （dev->subordinate） { if （！pci_bus_trylock（dev->subordinate）） { pci_dev_unlock（dev）; /* <- 解锁桥接设备 */ 转到解锁; } }在 a4e772898f8b 之后，不再采取桥接设备锁定，但失败路径上的 pci_dev_unlock （dev） 保留在原处，从而导致该缺陷。这会产生以下两种错误之一：1. 警告无人持有锁时正在解锁锁。2. 错误解锁属于另一线程的锁。通过删除故障路径上现在冗余的 pci_dev_unlock （dev） 修复了此问题。[Keith https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com后来在 ]（CVE-2026-43211）

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

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

  - netfilter：nf_conntrack_h323：修复 decode_choice（） 中的 OOB 读取 在 decode_choice（） 中，get_len（） 之前的边界检查使用变量“len”，该变量在函数顶部的初始化仍然为 0：unsigned int type， ext， len = 0;...if （ext ||（son->attr &; OPEN））{ BYTE_ALIGN（bs）; if （nf_h323_error_boundary（bs， len， 0）） /* len 在此处为 0 */ 返回 H323_ERROR_BOUND; len = get_len（bs）; /* OOB 读取 */ 当比特流完全被消耗 （bs->cur == bs->end） 时，检查 nf_h323_error_boundary（bs， 0， 0） 计算结果为 （bs->cur + 0 > bs->end），这是错误的。然后，后续 get_len（） 调用取消引用 *bs->cur++，读取超过缓冲区末尾的 1 个字节。如果该字节设置了位 7，get_len（） 也会读取第二个字节。可通过在 nf_conntrack_h323 帮助程序处于活动状态的情况下，将具有恰好包含 2 字节的 PER 编码数据（{0x08， 0x00}）的用户用户信息元素的用户-用户信息元素）发送到端口 1720 来远程触发此漏洞。解码器在到达此代码路径之前完全消耗 PER 缓冲区，从而导致 AddressSanitizer 确认的 1-2 字节堆缓冲区溢出读取。通过检查 2 个字节（get_len（） 可以读取的最大值）而非未初始化的“len”来修复此问题。这与同一文件中所有其他 get_len（） 调用站点使用的模式相匹配，其中调用程序在调用 get_len（） 之前检查 2 字节的可用数据。
    (CVE-2026-43233)

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

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

  - ipvs：修复ip_vs_add_service错误路径中的空取消引用 当 ip_vs_bind_scheduler（） 在 ip_vs_add_service（） 中成功时，本地变量 sched 将设置为 NULL。如果 ip_vs_start_estimator（） 随后失败，out_err清理将调用 ip_vs_unbind_scheduler（svc， sched） 并添加 sched == NULL。
    ip_vs_unbind_scheduler（） 通过了 cur_sched NULL 检查（因为成功的绑定设置了 svc->scheduler），但随后在 sched->done_service 取消引用 NULL sched 参数，进而在从 NULL 偏移0x30时造成内核错误。哎呀：一般保护错误，[..][#1] PREEMPT SMP KASAN NOPTI KASAN：范围内的 null-ptr-deref [0x0000000000000030-0x0000000000000037] RIP：0010：ip_vs_unbind_scheduler （net/netfilter/ipvs/ip_vs_sched.c：69） 调用跟踪： <TASK> ip_vs_add_service.isra.0 （net/netfilter/ipvs/ip_vs_ctl.c：1500） do_ip_vs_set_ctl （net/netfilter/ipvs/ip_vs_ctl.c：2809） nf_setsockopt （net/netfilter/nf_sockopt.c：102） [..]通过在成功绑定之后不清除本地 sched 变量的方式进行了修复。ip_vs_unbind_scheduler（） 已经检测是否通过 svc->scheduler 安装了计划程序，并将 sched 保持为非空可确保错误路径将正确的指针传递到 ip_vs_unbind_scheduler（） 和 ip_vs_scheduler_put（）。虽然该缺陷较旧，但在 ip_vs_start_estimator（） 调用之后采用新的错误路径时，会在较新的内核 （6.2） 中弹出问题。
    (CVE-2026-43086)

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

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

  - ntb：ntb_hw_switchtec：修复 0 mw lut 的偏移 MW LUT 数取决于 NTB 配置，可设置为零，在这种情况下rounddown_pow_of_two将造成未定义的行为，不应执行。此修补程序可确保对有效值调用 rounddown_pow_of_two。（CVE-2026-43141）

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

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

  - kcm：修复部分 sendmsg 错误的 frag_list 中的零碎片 skb Syzkaller 报告，处理frag_list中含有零碎片 skb 的消息时，kcm_write_msgs（） 中存在警告。当 kcm_sendmsg（） 在当前 skb 中填充MAX_SKB_FRAGS片段时，它会分配一个新的 skb （tskb） 并在复制数据之前将其链接到frag_list。如果复制随后失败（例如来自用户内存的 -EFAULT），tskb 仍保留在frag_list中，碎片为零：head skb（消息正在组装中，尚未sk_write_queue）+-----------+ |碎片[17] |（MAX_SKB_FRAGS，全部填满数据） |frag_list-+--> tskb +-----------+ +----------+ |碎片[0] |（空！ 填充前复制失败） +----------+ 对于已复制部分数据的SOCK_SEQPACKET，错误路径通过partial_message保存此消息以供以后完成。对于 SOCK_SEQPACKET，sock_write_iter（） 自动设置MSG_EOR，因此后续的零长度 write（fd， NULL， 0） 完成消息并将其排队到 sk_write_queue。然后 kcm_write_msgs（） 遍历frag_list并命中：WARN_ON（！skb_shinfo（skb）->nr_frags） TCP 具有类似的模式，在数据复制之前 skb 会被排队，并在数据复制失败时通过 tcp_remove_empty_skb（） 清除。KCM 缺少等效的清理操作。通过在分配新的 frag_list 条目时跟踪前置 skb （frag_prev） 修复此问题。出错时，如果尾部 skb 具有零碎片，则使用 frag_prev 在 O（1） 中取消链接并释放它，而无需遍历单链接的frag_list。frag_prev可以安全地取消引用，因为整个消息链仅在本地（或 kcm->seq_skb 中）保存，并且直到 MSG_EOR 才会添加到sk_write_queue中，因此发送路径无法将其释放到我们下面。还应将WARN_ON更改为 WARN_ON_ONCE，以免以某种方式重复命中该条件时淹没日志。内核树中当前无任何 KCM 自我测试;[1] 提供了一个简单的复制品。[1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa （CVE-2026-43244）

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

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

  - drm/amd/display：为 dcn401 添加信号类型检查 get_phyd32clk_src 尝试访问 dpia 链接上的链接 enc 将导致崩溃，否则 （CVE-2026-43243）

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

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

  - ASoC：SOF：Intel：had：修复空指针取消引用 如果计算机驱动程序中的 DAI 链接与拓扑结构中存在不匹配，则可能未设置回放/捕获小组件，尤其是在使用虚拟 DAI 链接的回显引用的环回捕获的情况下。未设置小组件时返回错误，以避免拓扑结构损坏时出现如下所示的空指针取消引用。RIP：
    0010：hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common] （CVE-2026-43137）

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

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

  - alpha：修复内存压缩期间的用户空间损坏 启用内存压缩时，Alpha 系统可遭受不定时的用户空间崩溃和堆损坏。症状包括 SIGSEGV、glibc 分配器失败（例如未对齐 tcache 区块）和编译器内部错误。禁用压缩或使用全局 TLB 无效时，失败消失。根本原因是页面迁移期间 TLB shootdown 不足。Alpha 依靠基于 ASN 的 MM 上下文滚动更新来实现指令缓存一致性，但仅此不足以防止过时的数据或指令转换幸存迁移。
    通过引入迁移专用帮助程序来修复此问题，该帮助程序结合了以下功能：- MM 上下文无效（ASN 滚动更新），- 每 CPU TLB 立即失效 （TBI），- 必要时同步跨 CPU shootdown。
    此帮助程序仅供迁移/压缩路径使用，以避免更改全局 TLB 语义。
    此外，请更新 flush_tlb_other（）、pte_clear（），以便使用 READ_ONCE（）/WRITE_ONCE（） 进行正确的 SMP 内存排序。这修复了在 UP 和 SMP Alpha 系统中观察到的崩溃。（CVE-2026-43258）

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

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

  - hwmon：（nct7363） 修复 nct7363_present_pwm_fanin 中的一个资源泄漏 调用 of_parse_phandle_with_args（） 时，调用程序负责调用 of_node_put（） 以释放设备节点的引用。在 nct7363_present_pwm_fanin 中，它不会释放引用，从而导致资源泄漏。
    (CVE-2026-43165)

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

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

  - misc：ti_fpc202：修复探测函数中潜在的内存泄漏 使用 for_each_child_of_node_scoped（） 简化代码并确保在循环范围结束时自动释放设备节点引用。
    (CVE-2025-71290)

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

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

  - iommu/vt-d：对于无可扩展模式的不可访问的 PCIe 设备跳过 dev-iotlb 刷新 启用了 ATS 并传递到用户空间的 PCIe 端点（例如 QEMU、DPDK）可以在其链接丢失时（因意外删除或链接错误）对主机进行硬锁定。提交 4fc82cd907ac（iommu/vt-d：设备断开连接时不发出 ATS 无效请求）将 pci_dev_is_disconnected（） 添加到 devtlb_invalidation_with_pasid（），因此仅在安全移除设备时跳过 ATS 无效，但仅当启用了 Intel IOMMU 可扩展模式时才适用。在禁用或不受支持可扩展模式的情况下，当 PCIe 端点的链路终止时，系统会发生硬锁定，这是因为 Intel IOMMU 无限期地等待无法完成的 ATS 无效化。调用跟踪：qi_submit_sync qi_flush_dev_iotlb
    __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist提交 81e921fd3216 （iommu/vt-d： 修复设备版本上的空域）将 intel_pasid_teardown_sm_context（） 添加到 intel_iommu_release_device（），从而调用 qi_flush_dev_iotlb（） 并在 PCIe 端点的链接丢失时对系统进行硬锁定。调用跟踪：
    qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 intel_context_flush_no_pasid device_pasid_table_teardown pci_pasid_table_teardown pci_for_each_dma_alias intel_pasid_teardown_sm_context intel_iommu_release_device iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slotpciehp_handle_presence_or_link_change pciehp_ist 有时，端点会在没有链接中断事件的情况下丢失连接（例如，由于链接错误）;终止进程 （virsh destroy） 然后硬锁定主机。调用跟踪：qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev __iommu_attach_device
    __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput pci_dev_is_disconnected（） 仅涵盖安全删除路径;pci_device_is_present（） 通过读取供应商/设备 ID 并在内部调用 pci_dev_is_disconnected（） 来测试可访问性。在 ConnectX-5（8 GT/s，x2）上，这需要 ~70 秒。由于仅在 {attach，release}_dev 路径（非热路径）上调用 __context_flush_dev_iotlb（），因此，在此处添加 pci_device_is_present（） 以跳过不可访问的设备并避免硬锁定。
    (CVE-2026-43161)

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

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

  - mailbox：防止 fw_mbox_index_xlate（） 中的越界访问 尽管引导“#mbox-cells”必须至少为 1，但设备树中仍存在许多“#mbox-cells = <0>;”的实例。如果是这样，并且相应的邮箱控制器不提供“fw_xlate”和 of_xlate“函数指针，则默认将使用”fw_mbox_index_xlate（）“，并且由于该函数中缺少边界检查，可能会发生越界访问。（CVE-2026-43281）

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

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

  - drm/amdgpu：验证用户队列大小限制 添加验证以确保用户队列大小满足硬件要求： - 大小必须为 2 的幂，以便有效封装环缓冲区 - 大小必须至少为 AMDGPU_GPU_PAGE_SIZE，以防止分配过小 这样可以防止可能导致 GPU 错误或意外行为的无效配置。（CVE-2026-43195）

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

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

  - rpmsg：core：修复 driver_override_show（） 中的争用并使用核心辅助函数 driver_override_show 函数在不保留device_lock的情况下读取driver_override字符串。但是，store 函数会在持有device_lock时修改并释放字符串。这会造成争用条件，其中，store 函数可在 show 函数读取字符串时释放字符串，进而导致释放后使用。若要修复此问题，请将 rpmsg_string_attr 宏替换为明确的 show 和 store 函数。新driver_override_store使用标准 driver_set_override 辅助函数。自引入 driver_set_override 以来，include/linux/rpmsg.h 中的注释已声明必须使用此帮助程序来设置或清理driver_override，但直到现在才更新实现。由于 driver_set_override 会在保留device_lock的同时修改并释放字符串，因此新driver_override_show现在可在读取操作期间正确保留device_lock以防止争用。
    此外，由于 rpmsg_string_attr 仅用于driver_override，因此删除宏可简化代码。（CVE-2025-71274）

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

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

  - dlm：验证 dlm_search_rsb_tree 中的长度 dlm_dump_rsb_name（） 中的 len 参数未经验证，并且来自网络消息。当它超过 DLM_RESNAME_MAXLEN 时，可导致 dlm_search_rsb_tree（） 中的越界写入。添加长度验证以防止潜在的缓冲区溢出。（CVE-2026-43125）

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

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

  - gfs2：fiemap 页面错误补丁 在 gfs2_fiemap（） 中，我们在保持 inode glock 的同时调用 iomap_fiemap（）。
    如果 fiemap 缓冲区的内存映射到相同的 inode，这可导致递归 glock 获取，并且访问它会触发页面错误。通过禁用 iomap_fiemap（） 的页面错误和手动缓冲区中的错误（如有必要）进行修复。修复 xfstest generic/742。（CVE-2026-43262）

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

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

  - media：mtk-mdp：修复探测函数中的错误处理。在错误处理路径上添加 mtk_mdp_unregister_m2m_device（） 以防止资源泄漏。添加对 vpu_get_plat_device（） 返回值的检查以防止空指针取消引用。vpu_get_plat_device（） 增加了返回平台设备的引用计数。添加 platform_device_put（） 以防止引用泄漏。（CVE-2026-43207）

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

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

  - hfsplus：将特殊 inode 假装为常规文件 由于提交 af153bb63a33（vfs：捕捉 may_open（） 中的无效模式）要求任何 inode 为 S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK 类型之一，因此将S_IFREG用于特殊 inode。（CVE-2026-43268）

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

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

  - LoongArch：使 cpumask_of_node（） 加强防御NUMA_NO_NODE cpumask_of_node（） 的 arch 定义无法处理NUMA_NO_NODE（这是有效索引），因此为此添加检查。（CVE-2026-43212）

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

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

  - ntfs3：修复 run_unpack_ex 中的循环锁定依赖关系 Syzbot 报告了 wnd->rw_lock （sbi->used.bitmap） 与 ni->file.run_lock 之间的循环锁定依赖关系。死锁情况：1. ntfs_extend_mft（） 先取 ni->file.run_lock，然后取 wnd->rw_lock。2. run_unpack_ex（） 采用 wnd->rw_lock 然后尝试获取 ntfs_refresh_zone（） 中的 ni->file.run_lock。这将造成 AB-BA 死锁。在 run_unpack_ex（） 中获取 run_lock 时，使用 down_read_trylock（） 而非 down_read（），以修复此问题。如果锁存在争夺，请跳过 ntfs_refresh_zone（） - 将在下一个 MFT 操作中刷新 MFT 区域。这打破了循环依赖关系，因为在保持 wnd->rw_lock 期间我们永远不会阻止等待run_lock。
    (CVE-2026-43127)

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

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

  - drm/amdgpu/ras：在检查错误页面之前移动 ras 数据分配 在极少数情况下，如果 eeprom 只有无效的地址条目，则会跳过分配，从而造成以下空指针问题 [ 547.103445] 缺陷：内核空指针取消引用，地址：0000000000000010 [ 547.118897] #PF：内核模式下的监督人读取访问权限 [ 547.130292] #PF：error_code（0x0000） - 不存在页面 [ 547.141689] PGD 124757067 P4D 0 [547.148842] 哎呀： 0000 [#1] PREEMPT SMP NOPTI [ 547.158504] CPU：49 PID：8167 Comm：cat 受感染：G OE 6.8.0-38-generic-Ubuntu #38[ 547.177998] 硬件名称：Supermicro AS -8126GS-TNMR/H14DSG-OD， BIOS 1.7 09/12/2025 [ 547.195178] RIP：0010：amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu] [ 547.210375] 代码：
    e8 63 78 82 c0 45 31 d2 45 3b 75 08 48 8b 45 a0 73 44 44 89 f1 48 8b 7d 88 48 89 ca 48 c1 e2 05 48 29 ca 49 8b 4d 00 48 01 d1 <48> 83 79 10 00 74 17 49 63 f2 48 8b 49 08 41 83 c2 01 48 8d 34 76 [ 547.252045] RSP： 0018：ffa0000067287ac0 EFLAGS：00010246 [ 547.263636] RAX：ff11000167c28130 RBX：ff11000127600000 RCX：
    0000000000000000 [ 547.279467] RDX：000000000000000000 RSI：00000000000000000 RDI：ff11000125b1c800 [547.295298] RBP：ffa0000067287b50 R08：00000000000000000 R09： 00000000000000000 [ 547.311129] R10：
    00000000000000000 R11： 00000000000000000 R12： 000000000000000000 [ 547.326959] R13： ff11000217b1de00 R14：
    00000000000000000 R15： 0000000000000092 [ 547.342790] FS： 0000746e59d14740（0000） GS：ff11017dfda80000（0000） knlGS：0000000000000000 [ 547.360744] CS：0010 DS： 0000 ES： 0000 CR0： 0000000080050033 [ 547.373489] CR2：
    0000000000000010 CR3： 000000019585e001 CR4： 00000000000f71ef0 [ 547.389321] PKRU： 55555554 [ 547.395316] 调用跟踪： [ 547.400737] [ <TASK>547.405386] ？ show_regs+0x6d/0x80 [ 547.412929] ？ __die+0x24/0x80 [547.419697] ？ page_fault_oops+0x99/0x1b0 [ 547.428588] ？ do_user_addr_fault+0x2ee/0x6b0 [ 547.438249] ？ exc_page_fault+0x83/0x1b0 [ 547.446949] ？ asm_exc_page_fault+0x27/0x30 [ 547.456225] ？ amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu] [ 547.470040] ？ mas_wr_modify+0xcd/0x140 [ 547.478548] sysfs_kf_bin_read+0x63/0xb0 [ 547.487248] kernfs_file_read_iter+0xa1/0x190 [ 547.496909] kernfs_fop_read_iter+0x25/0x40 [ 547.506182] vfs_read+0x255/0x390 这还会导致分配给负值的空间。在错误页面检查之前移动数据分配调用可解决这两个问题。（CVE-2025-71293）

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

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

  - md-cluster：修复 process_metadata_update 中的空指针取消引用 函数 process_metadata_update（） 盲目地取消引用 wait_event（） 宏中的“线程”指针（通过 rcu_dereference_protected 获取）。虽然代码注释指出后台程序线程必须存在，但在 MD 数组启动序列 （md_run） 期间存在有效的争用条件窗口：1. 调用 bitmap_load（），这将调用 md_cluster_ops->join（）。2. join（） 启动cluster_recv线程 （recv_daemon）。3. 此时，recv_daemon处于活动状态并正在处理消息。4. 但是，mddev->thread（主要 MD 线程）直到稍后在 md_run（） 中才会初始化。如果在此特定窗口期间从远程节点收到METADATA_UPDATED消息，将在 mddev->thread 仍为空时调用 process_metadata_update（），从而导致内核错误。要解决此问题，我们必须验证“线程”指针。如果它是 NULL，我们将释放保留的锁定 （no_new_dev_lockres） 并提前返回，安全地忽略更新请求，因为数组尚未完全准备好处理它。（CVE-2026-43271）

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

ID	名称	严重性
312762	Linux Distros 未修补的漏洞：CVE-2026-43269	medium
312761	Linux Distros 未修补的漏洞：CVE-2026-43196	high
312760	Linux Distros 未修补的漏洞：CVE-2026-43180	high
312759	Linux Distros 未修补的漏洞：CVE-2026-43189	medium
312758	Linux Distros 未修补的漏洞：CVE-2026-43095	medium
312757	Linux Distros 未修补的漏洞：CVE-2026-43272	medium
312756	Linux Distros 未修补的漏洞：CVE-2026-43185	critical
312755	Linux Distros 未修补的漏洞：CVE-2025-71272	medium
312754	Linux Distros 未修补的漏洞：CVE-2026-43218	medium
312753	Linux Distros 未修补的漏洞：CVE-2026-43267	medium
312752	Linux Distros 未修补的漏洞：CVE-2025-71286	medium
312751	Linux Distros 未修补的漏洞：CVE-2026-43081	medium
312750	Linux Distros 未修补的漏洞：CVE-2026-43236	high
312749	Linux Distros 未修补的漏洞：CVE-2026-43204	medium
312748	Linux Distros 未修补的漏洞：CVE-2026-43239	high
312747	Linux Distros 未修补的漏洞：CVE-2026-43261	medium
312746	Linux Distros 未修补的漏洞：CVE-2026-43245	high
312745	Linux Distros 未修补的漏洞：CVE-2026-43162	medium
312744	Linux Distros 未修补的漏洞：CVE-2026-43194	high
312743	Linux Distros 未修补的漏洞：CVE-2026-43279	high
312742	Linux Distros 未修补的漏洞：CVE-2026-43134	high
312741	Linux Distros 未修补的漏洞：CVE-2026-43273	medium
312740	Linux Distros 未修补的漏洞：CVE-2026-43215	high
312739	Linux Distros 未修补的漏洞：CVE-2026-43187	high
312738	Linux Distros 未修补的漏洞：CVE-2026-43143	medium
312737	Linux Distros 未修补的漏洞：CVE-2026-43100	medium
312736	Linux Distros 未修补的漏洞：CVE-2026-43264	medium
312735	Linux Distros 未修补的漏洞：CVE-2026-43227	medium
312734	Linux Distros 未修补的漏洞：CVE-2026-43211	high
312733	Linux Distros 未修补的漏洞：CVE-2026-43233	high
312732	Linux Distros 未修补的漏洞：CVE-2026-43086	medium
312731	Linux Distros 未修补的漏洞：CVE-2026-43141	high
312730	Linux Distros 未修补的漏洞：CVE-2026-43244	medium
312729	Linux Distros 未修补的漏洞：CVE-2026-43243	medium
312728	Linux Distros 未修补的漏洞：CVE-2026-43137	medium
312727	Linux Distros 未修补的漏洞：CVE-2026-43258	high
312726	Linux Distros 未修补的漏洞：CVE-2026-43165	medium
312725	Linux Distros 未修补的漏洞：CVE-2025-71290	medium
312724	Linux Distros 未修补的漏洞：CVE-2026-43161	medium
312723	Linux Distros 未修补的漏洞：CVE-2026-43281	high
312722	Linux Distros 未修补的漏洞：CVE-2026-43195	medium
312721	Linux Distros 未修补的漏洞：CVE-2025-71274	medium
312720	Linux Distros 未修补的漏洞：CVE-2026-43125	critical
312719	Linux Distros 未修补的漏洞：CVE-2026-43262	medium
312718	Linux Distros 未修补的漏洞：CVE-2026-43207	high
312717	Linux Distros 未修补的漏洞：CVE-2026-43268	medium
312716	Linux Distros 未修补的漏洞：CVE-2026-43212	high
312715	Linux Distros 未修补的漏洞：CVE-2026-43127	medium
312714	Linux Distros 未修补的漏洞：CVE-2025-71293	medium
312713	Linux Distros 未修补的漏洞：CVE-2026-43271	medium

检测

Nessus 的 Misc. 系列

medium

high

high

medium

medium

medium

critical

medium

medium

medium

medium

medium

high

medium

high

medium

high

medium

high

high

high

medium

high

high

medium

medium

medium

medium

high

high

medium

high

medium

medium

medium

high

medium

medium

medium

high

medium

medium

critical

medium

high

medium

high

medium

medium

medium