CVE-2026-89590

What it actually does

Error-path handling in the Linux kernel accel/rocket driver's rocket_job_run() fails after taking an extra dma_fence reference for job->done_fence. On failure the extra fence reference is not released (reference leak), pm_runtime_get_sync() has already incremented the runtime PM usage count even when resume fails so the NPU usage count is never balanced (the accelerator cannot suspend), and a valid but unsignaled fence is returned to the DRM scheduler, which WARNs when it drops that fence. The result is local resource leakage, pinned power state for the NPU, and a kernel warning—not memory corruption or remote code execution.

Why it matters to the business

Hosts that load the Rockchip NPU accel/rocket driver can suffer denial of service through leaked kernel fence references, inability of the neural accelerator to enter low power, higher energy use, and kernel WARNs that may trigger crash dumps or operational noise. Likelihood is low: EPSS is about 0.002 and flat over 30 days, the CVE is not in CISA KEV, ransomware use is not reported, and exploit maturity is none. About 37 days have passed since publication. Urgency is moderate only for fleets that actually ship this driver (embedded, edge, and NPU-equipped Linux devices) and low for general-purpose servers without it.

How an attack unfolds

This is a local, driver-specific availability issue. An unprivileged or privileged local process that can open the rocket DRM/accel device and submit jobs can induce an error after rocket_job_run() has taken an extra fence reference (for example a runtime PM resume failure or a later setup failure). The kernel then leaks the fence and PM references and may hand an unsignaled fence to the DRM scheduler, producing the pending-signals WARN. Repeating failed job submissions can accumulate leaks and keep the NPU from suspending. There is no described remote unauthenticated path, no public exploit, and no named threat actor or ransomware campaign associated with this CVE.

How to fix it

Apply a Linux kernel update that includes the accel/rocket fix for rocket_job_run() error paths: switch pm_runtime_get_sync() to pm_runtime_resume_and_get() so the usage count is auto-balanced on failure, drop both fence references on error, and return ERR_PTR(ret) instead of an unsignaled fence (consolidated goto error labels as in the upstream change). Take the corresponding vendor or distro kernel security update when one is published; this input does not list specific fixed package versions. If the NPU is unused, blacklist or unload the rocket module as a compensating control until the kernel is patched. Do not attempt to paper over leaks with userspace workarounds.

How to confirm the fix worked

Confirm the running kernel changelog or stable commit contains the rocket_job_run() error-path fix and that the driver uses pm_runtime_resume_and_get(), releases fence references on failure, and returns ERR_PTR rather than an unsignaled fence. Inventory exposure with module and device checks (rocket/accel present vs not). After patching, failed job submissions should not increment an unbalanced PM usage count, should not leak dma_fence objects, and should not produce DRM scheduler WARNs about fences released with pending signals. Compare kernel package version against the vendor advisory once fixed versions are published.

Typical attack path

1. Obtain local access on a Linux host where the accel/rocket module is loaded and the NPU accel device is reachable.
2. Open the rocket DRM/accel device and submit jobs that enter rocket_job_run().
3. Force an error after dma_fence_get() on job->done_fence (for example failed runtime PM resume or a later failure in the job-run path).
4. Cause the kernel to leak the extra fence reference and the PM usage count and/or return an unsignaled fence to the DRM scheduler.
5. Repeat failed submissions to accumulate leaks, pin the NPU awake, and generate kernel WARNs as a local denial of service.

How to detect it

This issue leaves host-local kernel artifacts, not network IOCs. Search dmesg, journalctl -k, and crash dumps on systems that load accel/rocket for DRM scheduler warnings that a fence was released with pending signals, rocket job-run failures, and runtime PM anomalies (NPU usage count stuck, device never suspending). Correlate with processes opening the rocket/accel DRM node and with bursts of failed job submissions. There is no public exploit tooling or named actor activity to hunt; absence of these logs does not prove the bug was never hit, only that the WARN path may not have fired.

• released with pending signals
• rocket_job_run
• accel/rocket
• drm_sched

What your security team should do

• Inventory which images and devices load accel/rocket or expose a Rockchip NPU accel node; deprioritize hosts without the driver.
• Patch or backport the kernel fix on all NPU-equipped systems; track vendor kernel advisories because no package-level fixed versions were supplied with this CVE.
• If the accelerator is not required, blacklist the rocket module until patched.
• Watch kernel logs for DRM fence pending-signal WARNs and rocket job-run failures as a stopgap detection control.
• Treat urgency as moderate for NPU fleets and low elsewhere given KEV=false, no ransomware use, EPSS ~0.002 with a flat 30-day trend, and exploit maturity none.