Bug 2562653 (CVE-2026-99144) - CVE-2026-99144 kernel: kernel: Denial of service via use-after-free in sched_ext
Summary: CVE-2026-99144 kernel: kernel: Denial of service via use-after-free in sched_ext
Keywords:
Status: NEW
Alias: CVE-2026-99144
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-10-28 10:43 UTC by OSIDB Bzimport
Modified: 2026-10-29 17:56 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-10-28 10:43:45 UTC
In the Linux kernel, the following vulnerability has been resolved:

sched_ext: Fix use-after-free of a destroyed user DSQ by a deferred reenqueue

A deferred reenqueue can read a freed user DSQ. The request stays on its
CPU's deferred list until run_deferred() takes it, and the RCU callback that
frees the DSQ assumes that the grace period has flushed it, so exit_dsq()
checks the per-CPU node without the deferred list lock. A grace period waits
for readers in flight, not for a pending run_deferred(). A run_deferred()
which starts after the grace period began can detach the request right
before the callback looks and then read the freed DSQ's id.

Cancel the pending requests before the grace period instead. The irq work
that frees the DSQ unlinks every CPU's request under the per-CPU deferred
list lock, and schedule_dsq_reenq() ignores a new request under the same
lock once the id is invalid. Only a run_deferred() that started before the
grace period can hold a request, and it runs with IRQs disabled, so the
grace period waits for it and nothing touches the DSQ after the callback.


Note You need to log in before you can comment on or make changes to this bug.