CVE-2026-89591

What it actually does

A local error-path bug in the Linux kernel accel/rocket driver leaves a job object with an uninitialized (NULL) IOMMU domain and can also double-free the job task array. On failed ioctl submit, rocket_job_cleanup() unconditionally drops job->domain before it is assigned and may free tasks twice after a copy failure, causing a kernel NULL-pointer dereference and related memory-safety failure in the accelerator job lifecycle.

Why it matters to the business

Systems that load the Rocket accelerator driver can be crashed by a local user or process, causing host outage, workload interruption, and possible reboot. Exploit maturity is none, EPSS is very low (~0.002) and flat over 30 days, the issue is not in KEV and is not associated with ransomware, so mass opportunistic risk is limited; impact is concentrated on hosts that actually use this driver. No named threat actors or downstream package counts are reported.

How an attack unfolds

An attacker who can already run code or issue ioctls on a machine with the Rocket driver loaded submits a job that fails during early allocation or task copy, before the per-file IOMMU domain is attached. The kernel then runs the common cleanup path on a job whose domain pointer was never set and may also free the task list twice, producing a kernel oops or memory-corruption crash rather than a clean error return. This is a local, driver-specific failure, not a remote unauthenticated compromise.

How to fix it

Apply the upstream Linux kernel fix that takes the per-file IOMMU domain reference before any error path can release the job, and that clears rjob->tasks after a failed rocket_copy_tasks() so cleanup cannot free the array twice. Upgrade to a vendor or distro kernel that includes that accel/rocket change; no specific fixed version numbers were provided in this record, so confirm the patch is present in your kernel changelog or stable tree. If the Rocket driver is unused, blacklist or do not load it as a compensating control until patched.

How to confirm the fix worked

Confirm the running kernel contains the accel/rocket change (domain taken before the first put/cleanup, tasks pointer cleared after free). Verify the rocket module is absent or the patched kernel is booted (uname and package changelog). After upgrade, exercise normal job submit and intentional early-failure submit paths in a test environment and confirm the host does not oops. Hosts without the driver loaded are not exposed.

Typical attack path

1. Obtain local execution or the ability to open the Rocket accelerator device node on a vulnerable kernel
2. Issue a job-submit ioctl that fails before the job domain is initialized (allocation or task-copy error)
3. Trigger rocket_job_put/cleanup while job->domain is still NULL and/or tasks are already freed
4. Cause a kernel oops or memory-corruption crash in the accelerator cleanup path, denying service on that host

How to detect it

This defect is a local kernel cleanup failure, not a network worm. Hunt for kernel oops/panic around rocket job cleanup rather than remote IOCs. Review dmesg, journalctl -k, and crash dumps (kdump/vmcore) for NULL deref or oops in rocket_job_cleanup, rocket_iommu_domain_put, rocket_ioctl_submit_job, or rocket_copy_tasks. Correlate with local processes issuing ioctls to the Rocket device shortly before the crash. No in-the-wild exploitation, named actors, or ransomware use is reported, so treat hits as suspicious local abuse or accidental trigger, not confirmed APT activity.

• rocket_job_cleanup
• rocket_iommu_domain_put
• rocket_ioctl_submit_job
• rocket_copy_tasks
• rocket_job_put
• Oops:.*rocket
• BUG: kernel NULL pointer dereference.*rocket
• accel/rocket

What your security team should do

• Inventory Linux hosts for the accel/rocket (Rocket accelerator) driver and prioritize those systems for kernel update
• Patch to a kernel that includes the domain-init-before-cleanup and tasks-clear fix; do not wait on KEV given this is still a local crash primitive
• If the hardware/driver is not required, prevent module load until patched
• Track distro/stable kernel advisories for the exact package version that carries this fix
• Given low EPSS, no KEV, and no known exploitation, treat as standard kernel hygiene rather than emergency ransomware response