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

  - ACPIEC ec_install_handlers() 返回时清除 acpi_ec_setup() 中的探测失败处理程序
    -EPROBE_DEFER 在精简硬件平台上已启动 EC 并安装地址空间处理程序并将 struct acpi_ec 指针作为处理程序上下文。但是 acpi_ec_setup() 会传播错误而不进行任何清理。然后调用程序 acpi_ec_add() 释放非启动实例的 struct acpi_ec在 ACPICA 中留下悬摆的处理程序上下文。任何访问 EC OpRegion 字段的后续 AML 评估都会分派至具有已释放指针的 acpi_ec_space_handler()从而造成释放后使用BUG
    KASANmutex_lock 中的 slab-free-after-free (kernel/locking/mutex.c:289) 由任务 init/1 调用跟踪在 addr ffff88800721de38 处进行大小 8 的写入 <TASK> mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio .c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) </TASK> 已分配按任务 1
    acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692) 由任务 1kfree 释放 (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751) () 当 GPIO IRQ 提供程序延迟探测时此缺陷会在精简硬件 EC 平台 (ec->gpe < 0) 上触发。过时处理程序存在后任何导致 AML 接触 EC OpRegion（battery、heat、backlight）的非特权 sysfs 读取都会运用悬摆指针。在清除 first_ec 之前通过调用 acpi_ec_setup() 的错误路径中的 ec_remove_handlers() 修复此问题。 ec_remove_handlers() 在操作前会检查每个 EC_FLAGS_* 位因此无论 ec_install_handlers() 进行到什么程度都可以安全调用-ENODEV未安装处理程序仅调用 acpi_ec_stop()
    -EPROBE_DEFER已安装处理程序删除处理程序停止 ECCVE-2026-31426]

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

检测

Linux Distros 未修补的漏洞：CVE-2026-31426

high Nessus 插件 ID 306184

版本 1.20