CVE-2026-89592

What it actually does

A local caller of the Linux kernel accel/rocket job-submit path can trigger two kernel-memory bugs in rocket_job_push(): a NULL pointer dereference if kvmalloc_array() fails, and a u32 integer overflow when summing unvalidated userspace in_bo_count and out_bo_count. The overflow undersizes the temporary GEM-object pointer array while later memcpy and object-lock loops still use the original counts, producing out-of-bounds reads/writes on kernel heap. Impact is kernel crash (DoS) and, depending on heap layout, potential memory corruption in kernel context.

Why it matters to the business

Systems that expose the rocket accelerator driver can be crashed by a local user, causing host or VM outages and interrupting any workloads sharing that kernel. Memory corruption raises a privilege-escalation and integrity risk on those hosts. EPSS is low (~0.002) and flat over 30 days, the issue is not in CISA KEV, exploit maturity is none, and it is not associated with ransomware campaigns, so mass remote exploitation is unlikely. Urgency is highest for fleets that load accel/rocket (AI/accelerator nodes); general-purpose servers without this driver have negligible exposure.

How an attack unfolds

An attacker who already has local code execution and access to the rocket accelerator device submits a job whose userspace-supplied input and output buffer-object counts are chosen so their 32-bit sum wraps. The kernel allocates a too-small pointer array (or fails the allocation entirely). Subsequent copies and object locking run with the original counts, either dereferencing a NULL pointer and panicking the kernel or writing past the undersized allocation. No remote, unauthenticated path is described; success depends on the driver being loaded and the caller being allowed to open the accel device. No named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Apply the upstream Linux kernel fix for rocket_job_push() that uses check_add_overflow() before allocating the combined GEM pointer array and that treats a failed kvmalloc_array() as an error instead of copying into a NULL pointer. Deploy a distribution or vendor kernel that includes that patch; no per-package fixed versions were supplied with this record, so take the newest stable/LTS kernel from your vendor that lists this CVE as resolved. If the rocket accelerator is not required, blacklist or do not load the module and restrict access to accel device nodes as a compensating control until kernels are updated.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory includes the rocket_job_push overflow and NULL-check fix. Verify accel/rocket is either patched or not loaded (lsmod / /sys/module). After upgrade, exercise normal job submission on a test host and confirm no oops. Code review or a patched-kernel binary check should show check_add_overflow on in_bo_count + out_bo_count and a NULL check on the kvmalloc_array result. Do not use overflowed count values as a production test.

Typical attack path

1. Obtain local access on a host where the accel/rocket driver is loaded and the device node is reachable.
2. Open the rocket accelerator interface with privileges sufficient to submit jobs.
3. Submit a job with userspace in/out buffer-object counts that overflow when added as u32, or that force allocation failure.
4. Kernel undersizes (or fails) the temporary GEM pointer array and then copies/locks using the original counts.
5. Result is a kernel NULL dereference panic or out-of-bounds access on the temporary array, causing denial of service and possibly further kernel-memory corruption.

How to detect it

Hunt for historical kernel oops/panic records, kdump/vmcore, and serial/console logs mentioning rocket_job_push, accel/rocket, or a NULL pointer dereference in that function. Correlate with local opens of accelerator device nodes and process activity around job submission. There are no public in-the-wild campaigns, ransomware use, or named APT associations, so treat hits as local abuse or accidental trigger rather than a known mass exploit. Review logs from publication date (2026-09-11) onward. Absence of oopses does not prove non-exploitation if the host was not capturing kernel logs.

• rocket_job_push
• accel/rocket
• NULL pointer dereference
• kvmalloc_array
• in_bo_count
• out_bo_count
• Unable to handle kernel NULL pointer dereference
• Oops: 0000
• /dev/accel

What your security team should do

• Inventory hosts that load accel/rocket or expose /dev/accel* and prioritize kernel updates there.
• Deploy vendor/stable kernels that include the rocket_job_push overflow and NULL-check fix; reboot into the patched kernel.
• If the driver is unused, prevent it from loading and tighten permissions on accelerator device nodes.
• Watch kernel logs for rocket_job_push oopses during the 37+ days this has been public, even though EPSS is low and KEV is false.
• Treat residual risk as local DoS/memory-corruption on accelerator nodes, not as a network wormable issue.