CVE-2026-89592: Linux Kernel Use-After-Free Vulnerability

CVE-2026-89592 is a use-after-free flaw in the Linux kernel's accel/rocket driver affecting memory allocation in rocket_job_push(). The vulnerability allows NULL pointer dereference and integer overflow. This post covers technical details, affected versions, impact assessment, and mitigation strategies.

CVE-2026-89592 Overview

CVE-2026-89592 is a Linux kernel vulnerability in the accel/rocket driver affecting the rocket_job_push() function. The flaw contains two related defects: a missing NULL check after kvmalloc_array() and an integer overflow in a u32 sum derived from userspace input. A local user submitting crafted GEM buffer object counts can trigger a kernel NULL pointer dereference or force out-of-bounds accesses on a temporary array. The upstream fix uses check_add_overflow() to validate the allocation size and adds a NULL check on the allocation result.

Critical Impact
Local userspace can crash the kernel via NULL pointer dereference or trigger out-of-bounds memory access through the Rocket accelerator ioctl path.

Affected Products

Linux kernel builds including the accel/rocket driver
Distributions shipping kernels prior to the fix commits a85402b, c1a5bf1, and dfff90a
Systems exposing the Rocket accelerator device node to unprivileged users

Discovery Timeline

2026-09-11 - CVE-2026-89592 published to NVD
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-89592

Vulnerability Analysis

The rocket_job_push() function allocates a temporary array using kvmalloc_array(job->in_bo_count + job->out_bo_count, sizeof(void *), GFP_KERNEL). It then copies input and output GEM object pointer lists into the buffer with two memcpy() calls. Neither the allocation result nor the sum of the counts is validated before use.

When kvmalloc_array() returns NULL under memory pressure or excessive size requests, the following memcpy() dereferences a NULL pointer and panics the kernel. This provides a reliable local denial-of-service primitive on affected builds.

The integer overflow is more consequential. Because in_bo_count and out_bo_count are both u32 and originate directly from the userspace fields in_bo_handle_count and out_bo_handle_count, an attacker can choose values whose sum wraps around inside 32-bit arithmetic. The allocation then reserves fewer entries than downstream code expects, while subsequent copy and locking operations continue to use the original larger counts.

Root Cause

Two defects share the same call site. First, the allocation return value is not checked before dereference [CWE-476]. Second, the count arithmetic lacks overflow protection [CWE-190], allowing a wrapped sum to produce an undersized allocation while the loop bounds remain unchanged.

Attack Vector

An attacker with access to the Rocket accelerator device node issues an ioctl carrying crafted in_bo_handle_count and out_bo_handle_count values. Choosing counts whose 32-bit sum wraps to a small value bypasses the intended allocation size. Follow-on memcpy() and object-locking loops then write and read past the allocated region on the kernel heap.

Refer to the upstream fix commits for the exact patched code: Kernel Git Commit A85402B, Kernel Git Commit C1A5BF1, and Kernel Git Commit DFFF90A.

Detection Methods for CVE-2026-89592

Indicators of Compromise

Kernel oops or panic traces referencing rocket_job_push in the call stack
Unexpected BUG: kernel NULL pointer dereference messages tied to the accel/rocket module
Slab corruption or KASAN reports on the kernel heap correlated with Rocket ioctl activity

Detection Strategies

Audit kernel logs for repeated crashes involving the Rocket accelerator driver on hosts exposing the device node.
Verify the installed kernel version against the stable trees carrying commits a85402b, c1a5bf1, and dfff90a.
Enable KASAN or slab debugging on test kernels to catch out-of-bounds accesses on the temporary bos array.

Monitoring Recommendations

Forward dmesg and journald kernel events to a central log platform and alert on rocket_job_push stack frames.
Track ioctl invocations against /dev/accel/* device nodes by unprivileged users.
Monitor for unexpected reboots or kernel panic dumps on systems with the Rocket driver loaded.

How to Mitigate CVE-2026-89592

Immediate Actions Required

Apply the upstream kernel patches referenced by commits a85402b, c1a5bf1, and dfff90a or upgrade to a distribution kernel that includes them.
Restrict access to Rocket accelerator device nodes so only trusted service accounts can issue ioctls.
Reboot affected hosts after patching to unload the vulnerable driver image.

Patch Information

The fix adds a check_add_overflow() guard on job->in_bo_count + job->out_bo_count before calling kvmalloc_array() and validates the allocation result for NULL before the subsequent memcpy() operations. Patches are available in the mainline and stable trees via the three commits listed in the references.

Workarounds

Unload the rocket kernel module on systems that do not require the accelerator: modprobe -r rocket.
Remove or tighten permissions on the associated /dev/accel/* character devices to prevent unprivileged ioctl access.
Constrain container and sandbox policies to block the Rocket device from untrusted workloads.

bash

# Configuration example
# Prevent the vulnerable driver from loading at boot
echo 'blacklist rocket' | sudo tee /etc/modprobe.d/blacklist-rocket.conf
sudo modprobe -r rocket

# Restrict device access if the driver must remain loaded
sudo chown root:root /dev/accel/accel0
sudo chmod 0600 /dev/accel/accel0