UBUNTU-CVE-2026-99183: Medium severity vulnerability
In the Linux kernel, the following vulnerability has been resolved: accel/rocket: search every core slot when looking up a scheduler schedtocore() walks rdev->cores[] up to rdev->numcores, and rocketremove() decrements numcores for every core it removes. Unbind a core that is not the last one and the cores behind it fall outside the search, so schedtocore() returns NULL for a core that is still bound and still running jobs. Neither caller checks the result: rocketjobrun(): rocketfencecreate(core), core->dev rocketjobtimedout(): deverr(core->dev, "NPU job timed out") Unbinding the middle core of the three on an RK3588 while three clients are submitting to all of them faults twice, once from the surviving core's job queue and once from its reset work: KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] Workqueue: fdad0000.npu drmschedrunjobwork [gpusched] pc : rocketjobrun+0x234/0x838 [rocket] Call trace: rocketjobrun+0x234/0x838 [rocket] drmschedrunjobwork+0x2cc/0xad8 [gpusched] processonework+0x640/0x14f0 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: rocket-reset-2 drmschedjobtimedout [gpusched] pc : rocketjobtimedout+0xf0/0x1e0 [rocket] Call trace: rocketjobtimedout+0xf0/0x1e0 [rocket] drmschedjobtimedout+0x188/0x6a0 [gpusched] Both are the third core: the workqueue names are its device and its core->index, and it was left at slot 2 while numcores had dropped to 2. Search all the slots that were allocated, the way findcorefordev() now does. A core that is still bound is then found, and the two callers get the pointer they already assume they have. This does not make unbinding one core out of several safe. An open client keeps an entity pointing at the scheduler of the core that went away: drmsched reports it as not ready for every job that lands on it, and the client waits in dmafencedefaultwait for a fence that will never signal. Stopping the NULL dereference is what belongs in a fix; the rest wants more thought.
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
Systems using the Linux kernel rocket accelerator driver with multiple bound cores are exposed when a core is removed while other cores remain bound and are running jobs. The reported scenario involved three cores on an RK3588 with clients submitting work to all of them.
What sequence triggers the fault?
Unbinding a core that is not the last entry causes cores after it to fall outside the scheduler lookup range. Jobs or timeout/reset work for a surviving core can then dereference a NULL core pointer.
What can be done if the fix cannot be deployed immediately?
Avoid unbinding a non-final rocket core while other bound cores may still have active job submissions or scheduler work. Coordinate core removal with workload shutdown so no jobs remain on surviving cores.
How can administrators identify a potentially affected failure?
Kernel logs may show KASAN null-pointer dereferences in rocket_job_run or rocket_job_timedout, including workqueue contexts such as drm_sched_run_job_work and rocket-reset-2. The fault may occur once from a surviving core's job queue and again from its reset work.