{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.113-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.11-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003ework, 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()    -\u003e intel_engine_pm_put()       -\u003e wakeref_put()  ASYNC1) wakeref_put() callback           -\u003e __engine_park()              -\u003e intel_gt_pm_put_async()                 -\u003e intel_gt_pm_put_async_untracked()                    -\u003e intel_wakeref_put_async()  ASYNC2) wakeref_put_async() callback           -\u003e __gt_park()              -\u003e intel_rps_park()                 -\u003e intel_rps_clear_active() [clear ACTIVE]                 WITH INTERRUPTS:                 -\u003e rps_disable_interrupts()                    -\u003e cancel_work_sync(rps-\u003ework)                    -\u003e rps_reset_interrupts() [rps-\u003epm_iir = 0]                 WITHOUT INTERRUPTS (TIMER mode):                 -\u003e rps_stop_timer()                    -\u003e cancel_work_sync(rps-\u003ework)  2) live_rc6_ctx_wa()    -\u003e intel_gt_wait_for_idle()       -\u003e intel_gt_retire_requests_timeout()          -\u003e dma_fence_wait_timeout()             -\u003e ops-\u003ewait() [i915_fence_wait()]                -\u003e i915_request_wait_timeout()                   -\u003e intel_rps_boost()                      -\u003e intel_rps_is_active() [check ACTIVE]                         [OPEN RACE WINDOW]                      -\u003e queue_work(rps-\u003ework)          -\u003e retire_requests()             -\u003e i915_request_retire()                -\u003e 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 \u0026\u0026 !client_boost)\" test (in TIMER mode rps-\u003epm_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() -\u003e    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-\u003einterrupts_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)",
  "id": "DEBIAN-CVE-2026-99005",
  "modified": "2026-10-24T05:47:28.036779501Z",
  "published": "2026-10-23T13:17:22.893Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-99005"
    }
  ],
  "upstream": [
    "CVE-2026-99005"
  ]
}