{
  "affected": [
    {
      "ranges": [
        {
          "events": [
            {
              "introduced": "4c95380701f58b8112f0b891de8d160e4199e19d"
            },
            {
              "fixed": "6d1890d3c6137ab523799765ae2de62cc05f116d"
            },
            {
              "fixed": "3dd52416e44a70bc993adb96d2e0d71b9ea21359"
            }
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "type": "GIT"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Linux",
        "name": "Kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.19.0"
            },
            {
              "fixed": "7.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89518.json"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Fix this_rq() assumptions in dispatch kfuncs\n\nUnder core scheduling, dispatch runs from within the core-wide pick and can\ntarget a sibling rq, so ops.dispatch() may execute on a CPU different from\nthe dispatched rq's. Several kfunc paths assumed the two always coincide:\n\n- scx_dsq_move() decided whether an rq lock is held by testing this_rq()'s\n  rq flags and lock-danced accordingly. A dispatch for a sibling took the\n  unlocked-context branch and acquired the source rq lock on top of the\n  already held dispatched rq lock which could deadlock.\n\n- scx_bpf_sub_dispatch() dispatched this_rq() with its stashed\n  sub_dispatch_prev, which is NULL when dispatching for a sibling.\n\n- finish_dispatch(), scx_bpf_dsq_reenq() and scx_bpf_dsq_nr_queued()\n  resolved SCX_DSQ_LOCAL to this CPU's local DSQ rather than the dispatched\n  rq's. The latter two are callable from other rq-locked operations too,\n  where SCX_DSQ_LOCAL now likewise resolves to the op's rq. This changes\n  behavior also without core scheduling, e.g. for ops.enqueue() running a\n  remote wakeup on the waking CPU, and is intended: which CPU happens to\n  execute an operation is incidental, the op's rq is what it is operating\n  on, and the resolution now matches the insert side where SCX_DSQ_LOCAL\n  dispatches land on the task's rq.\n\nUse the rq tracked by scx_locked_rq(), which is set to the dispatched rq\naround ops invocations and NULL in unlocked contexts.",
  "id": "CVE-2026-89518",
  "modified": "2026-09-13T03:30:41.414028624Z",
  "published": "2026-09-11T19:44:01.222Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3dd52416e44a70bc993adb96d2e0d71b9ea21359"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6d1890d3c6137ab523799765ae2de62cc05f116d"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89518.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89518"
    },
    {
      "type": "PACKAGE",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
    }
  ],
  "schema_version": "1.9.0",
  "summary": "sched_ext: Fix this_rq() assumptions in dispatch kfuncs"
}