CVE-2026-99005— i915 驱动中断掩码处理错误漏洞
一分钟漏洞结论
影响对象
Linux Linux
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
在 Linux 内核中，以下漏洞已得到修复： drm/i915/gt：仅在 ACTIVE 状态为真时取消中断屏蔽 在 读取过时的 ACTIVE 状态并排队 之间存在一个微小的竞态窗口。在此期间，由于 wakeref 释放触发的异步调用，ACTIVE 状态可能会发生改变。这意味着 可能在 GT（图形技术单元）已停驻（parked）后被触发，从而导致在未持有 PM（电源管理）唤醒锁（wakelock）的情况下取消 RPS（运行时电源调度）电源管理中断的屏蔽。这一事件序列可能在 自测中被观察到： 1. -> -> ASY
可能的 ATT&CK 技术 1 AI
T1190 · Exploit Public-Facing Application影响版本矩阵 12
| 厂商 | 产品 | 版本范围 | 状态 |
|---|---|---|---|
| Linux | Linux | 3e7abf8141935ded77abeb622480bf4a14241ece< 77abc1837c9651c8f43f7f7f336d10093eeb7745 |
affected |
3e7abf8141935ded77abeb622480bf4a14241ece< 60f58da15f8c8e39706c564f9251de3626636dce |
affected | ||
3e7abf8141935ded77abeb622480bf4a14241ece< 0b4a0fb98b9ffeac36798bbd369c821605cae70f |
affected | ||
3e7abf8141935ded77abeb622480bf4a14241ece< 49d349c42cf5ebaa878d02699c632c9d883d935f |
affected | ||
3e7abf8141935ded77abeb622480bf4a14241ece< 5346b1cec6afa4f9b4b49a9f84e3cfef95a3f7bb |
affected | ||
5.5 |
affected | ||
< 5.5 |
unaffected | ||
6.6.160≤ 6.6.* |
unaffected | ||
| … +4 条更多 | |||
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2026-99005 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
drm/i915/gt: Unmask interrupts only when ACTIVE is true
来源: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Unmask interrupts only when ACTIVE is true
There is a small race window between intel_rps_boost() reading
a stale ACTIVE state and queuing rps->work, where ACTIVE may be
changed via asynchronous calls triggered by wakeref drop.
This means that rps_work() could be triggered after the GT has
been parked, so unmasking RPS PM interrupts would happen without
holding PM wakelock. This sequence of events may be observed
during live_rc6_ctx_wa() selftest:
1) live_rc6_ctx_wa()
-> intel_engine_pm_put()
-> wakeref_put()
ASYNC1) wakeref_put() callback
-> __engine_park()
-> intel_gt_pm_put_async()
-> intel_gt_pm_put_async_untracked()
-> intel_wakeref_put_async()
ASYNC2) wakeref_put_async() callback
-> __gt_park()
-> intel_rps_park()
-> intel_rps_clear_active() [clear ACTIVE]
WITH INTERRUPTS:
-> rps_disable_interrupts()
-> cancel_work_sync(rps->work)
-> rps_reset_interrupts() [rps->pm_iir = 0]
WITHOUT INTERRUPTS (TIMER mode):
-> rps_stop_timer()
-> cancel_work_sync(rps->work)
2) live_rc6_ctx_wa()
-> intel_gt_wait_for_idle()
-> intel_gt_retire_requests_timeout()
-> dma_fence_wait_timeout()
-> ops->wait() [i915_fence_wait()]
-> i915_request_wait_timeout()
-> intel_rps_boost()
-> intel_rps_is_active() [check ACTIVE]
[OPEN RACE WINDOW]
-> queue_work(rps->work)
-> retire_requests()
-> i915_request_retire()
-> intel_rps_dec_waiters() [from 1 to 0]
If ASYNC1 and ASYNC2 would execute during [OPEN RACE WINDOW],
then:
3) rps_work() executes from the workqueue and may satisfy
"(!pm_iir && !client_boost)" test (in TIMER mode rps->pm_iir
is zeroed by an earlier rps_work() call or never gets a new
value after previous intel_rps_unpark() event), so it jumps
to "out" label, bypassing intel_rps_is_active() guard and
executes gen6_gt_pm_unmask_irq();
4) GT is parked and runtime PM wakelock is dropped, so only
a raw reference in __gt_park() ->
intel_display_power_put_async() remains for 100ms, then the
MMIO write in gen6_gt_pm_unmask_irq() detects missing
wakelock via assert_rpm_wakelock_held() and emits
"RPM wakelock ref not held during HW access" tainting kernel.
Commit 3e7abf814193 ("drm/i915: Extract GT render power state management")
dropped the "if (rps->interrupts_enabled)" guard that
gen6_pm_rps_work() had around this unmask in i915_irq.c.
INTEL_RPS_ACTIVE brackets the same window, since it is set in
intel_rps_unpark() before rps_enable_interrupts() and
rps_start_timer() and cleared in intel_rps_park() before
rps_stop_timer() and rps_disable_interrupts().
Skip unmasking when RPS is no longer active (reaching unmask
operation is independent of INTERRUPT mode). This does not
prevent RPS operation from resuming on the next unpark.
In interrupt mode, intel_rps_unpark() calls
rps_enable_interrupts(), which enables and unmasks the PM
interrupts. In timer mode, it calls rps_start_timer(),
restarting periodic engine-busyness evaluation. The timer
generates software RPS events and queues rps_work() directly,
independently of PM interrupt delivery. Neither mode requires
the late worker to unmask interrupts while the GT is parked
(cherry picked from commit ca4a6deadad15b91ee083afe445fa6bdbfb68206)
来源: CVE Program / CVE List V5
CVSS Information
N/A
来源: CVE Program / CVE List V5
Vulnerability Type
N/A
来源: CVE Program / CVE List V5
受影响产品
二、漏洞 CVE-2026-99005 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2026-99005 的情报信息
请登录查看更多情报信息。
CVE-2026-99005 补丁与修复 (5)
同批安全公告 · Linux · 2026-10-23 · 共 217 条
| CVE-2026-98959 | 9.8 CRITICAL | btrfs 扩展属性替换处理远程代码执行漏洞 |
| CVE-2026-99078 | 9.8 CRITICAL | Mellanox mlx5e MPWQE重试时XSK缓冲区释放漏洞 |
| CVE-2026-99079 | 9.8 CRITICAL | Mellanox mlx5e 驱动 XSK 缓冲区释放漏洞 |
| CVE-2026-98988 | 8.8 HIGH | Linux 5.13 命名空间越界漏洞 |
| CVE-2026-99083 | 8.8 HIGH | ksmbd 的 krb5_authenticate() 函数堆越界写漏洞 |
| CVE-2026-99082 | 8.8 HIGH | KVM x86 内存管理漏洞 |
| CVE-2026-98870 | 8.8 HIGH | ksmbd 会话清理时存在通道移除逻辑漏洞 |
| CVE-2026-98980 | 8.8 HIGH | namei 遍历中过度挂载条目信息泄露漏洞 |
| CVE-2026-98981 | 8.8 HIGH | Linux 内核命名空间 dentry 解挂载前未哈希漏洞 |
| CVE-2026-99042 | 8.4 HIGH | io_uring 24 字节 sockaddr_in6 过滤字段填充漏洞 |
| CVE-2026-98978 | 8.4 HIGH | Linux 命名空间 锁定挂载永不失效漏洞 |
| CVE-2026-99064 | 8.1 HIGH | CIPSO 缓存选项偏移调整漏洞 |
| CVE-2026-98968 | 8.1 HIGH | AMT 中继通用查询远程代码执行漏洞 |
| CVE-2026-98993 | 7.8 HIGH | Linux 内核命名空间 clone_mnt 挂载点继承漏洞 |
| CVE-2026-99053 | 7.8 HIGH | Linux TIPC 节点引用漏洞 |
| CVE-2026-99054 | 7.8 HIGH | Linux TIPC 拓扑服务队列资源泄漏漏洞 |
| CVE-2026-99056 | 7.8 HIGH | strparser 解析器关闭时竞态条件漏洞 |
| CVE-2026-99002 | 7.8 HIGH | vmwgfx 驱动用户空间 pitch 参数验证漏洞 |
| CVE-2026-98899 | 7.8 HIGH | Linux netfilter ipset 竞态条件漏洞 |
| CVE-2026-99006 | 7.8 HIGH | i915 GEM 执行数组越界漏洞 |
显示前 20 条，共 217 条。 查看全部 → →