CVE-2026-89590: accel/rocket: Fix error path handling in rocket_job_run()
In the Linux kernel, the following vulnerability has been resolved:
accel/rocket: Fix error path handling in rocketjobrun()
In rocketjobrun(), after taking an extra fence reference for job->donefence via dmafenceget(), the error paths have three bugs:
- The dmafence reference held by job->donefence is never released, causing a reference leak. - pmruntimegetsync() increments the usage counter even on failure, but the error path does not decrement it, leaking the runtime PM reference and preventing the NPU from suspending. - A valid but unsignaled fence is returned to the DRM scheduler, which triggers WARN("Fence ... released with pending signals!") when the scheduler drops its reference.
Fix by replacing pmruntimegetsync() with pmruntimeresumeandget() which auto-balances the usage counter on failure, releasing both fence references on error, and returning ERRPTR(ret) instead of the unsignaled fence.
[tomeu: Refactored error paths to use consolidated goto labels]
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
accel/rocketto a version that resolves this vulnerability.Patch tomeu: Refactored error paths to use consolidated goto labels - Configuration
In rocket_job_run(), replace all uses of pm_runtime_get_sync() with pm_runtime_resume_and_get() so the runtime PM usage counter is auto-balanced and does not leak on failure.
Linux kernel pm_runtime (rocket_job_run) pm_runtime_get_sync() = replace with pm_runtime_resume_and_get() - Operational
Verify rocket_job_run() error paths correctly release any extra dma_fence reference taken for job->done_fence (dma_fence_get()) so that on failure the fence reference is decremented and the NPU can suspend; also ensure error paths return the correct fence state (not ERR_PTR(ret) where an unsignaled fence should be returned/released).
Event History
Frequently Asked Questions
What conditions must occur for the faulty paths to be reached?
A job must enter an error path after an extra reference is taken on its completion fence. One identified case is failure of the runtime PM resume operation.
What symptoms could indicate that a system is affected?
The DRM scheduler can emit a warning that a fence was released with pending signals. Runtime PM references can also remain elevated, preventing the NPU from suspending.
What is the practical mitigation if the fix cannot be applied immediately?
No workaround is provided in the available information. The issue is corrected by using the updated error handling, which balances runtime PM state, releases fence references, and returns an error rather than an unsignaled fence.