{
  "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"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  futex: Prevent rcuwait use-after-free during requeue PI  On PREEMPT_RT, FUTEX_CMP_REQUEUE_PI can trigger a KASAN report (slab-out-of-bounds) in futex_requeue_pi_complete() invocation of rcuwait_wake_up().  The futex_q used by futex_wait_requeue_pi() is allocated on the waiter's stack. An early wakeup can race with a PI requeue as follows:          waiter                          requeue task         ------                          ------------ futex_wait_requeue_pi()   futex_do_wait()     schedule()                                        futex_requeue                                          futex_proxy_trylock_atomic()                                            futex_requeue_pi_prepare()                                             Q_REQUEUE_PI_NONE -\u003e Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal wakes waiter *   futex_requeue_pi_wakeup_sync()    Q_REQUEUE_PI_IN_PROGRESS -\u003e Q_REQUEUE_PI_WAIT                                            requeue_pi_wake_futex                                              futex_requeue_pi_complete()                                                cmpxchg Q_REQUEUE_PI_WAIT -\u003e Q_REQUEUE_PI_LOCKED     rcuwait_wait_event()       if (atomic_read(\u0026q-\u003erequeue_state) != Q_REQUEUE_PI_WAIT)        break /* no schedule() */   /* q.pi_state-\u003eowner == current */  futex_private_hash_put()  /* return from syscall */                                               rcuwait_wake_up(\u0026q-\u003erequeue_wait)                                                 /* q is gone */  futex_requeue_pi_complete() publishes Q_REQUEUE_PI_LOCKED before calling rcuwait_wake_up(). The waiter observes this state in rcuwait_wait_event() before invoking schedule() in rcuwait_wait_event(). Here, the waiter is free leave the syscall before requeue task can complete the wake.  To address this race skip rcuwait_wake_up() in the Q_REQUEUE_PI_LOCKED case. This state is only published by requeue_pi_wake_futex(), which saves q-\u003etask before futex_requeue_pi_complete() and wakes the waiter via wake_up_state().  This wake is intended to wake the waiter from its futex_do_wait() sleep. If the waiter is still sleeping there, it can not get into the Q_REQUEUE_PI_WAIT state (and require this removed wake). Should the waiter be woken up from futex_do_wait() by other means (as in this example) and sleep in futex_requeue_pi_wakeup_sync() then the wake_up_state() from requeue_pi_wake_futex() will wake it, too. Should the waiter task terminate before wake_up_state() had a chance to wake the task then the task pointer does not become invalid because the futex_hash_bucket::lock is held and the task pointer is RCU protected.  [bigeasy: Updated comment and commit message]",
  "id": "DEBIAN-CVE-2026-90003",
  "modified": "2026-09-17T04:47:33.036838795Z",
  "published": "2026-09-16T11:17:12.810Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-90003"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-90003"
  ]
}