CVE-2026-89814

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The OOB is in amdgpu_device_enforce_isolation() and amdgpu_vm_flush(), reached only via local DRM ioctls on /dev/dri/renderD* (AMDGPU_CS and GEM_VA/VM updates that schedule SDMA jobs through amdgpu_job_prepare_job/amdgpu_ib_schedule). There is no network, adjacent-radio, or physical packet path.

AC:LAttack complexity, low

Unassigned rings already have xcp_id=AMDGPU_XCP_NO_PARTITION (~0), so indexing adev->isolation[MAX_XCP] is deterministic on each SDMA or GFX/compute job. The attacker only needs to submit ordinary command buffers or VA maps; no race or uninfluenced layout is required.

PR:LPrivileges required, low

AMDGPU_CS, GEM_VA, and related ioctls are DRM_AUTH|DRM_RENDER_ALLOW with no capability check, so any unprivileged local user with render-node access (render/video group, Android GPU clients, multi-tenant cloud GPU VMs) can reach the scheduler without init-namespace root.

UI:NUser interaction, none

The attacker opens the render node and submits their own command buffers or GEM_VA maps; no separate victim action such as mounting a filesystem, opening a file, or interacting with another user's GPU context is required.

S:UScope, unchanged

The isolation[] out-of-bounds access corrupts host kernel memory inside the amdgpu driver. It does not cross a VM, IOMMU/DMA, or guest-to-host boundary into a different security authority.

C:HConfidentiality impact, high

Indexing isolation[ring->xcp_id] with ~0 is an unbounded kernel out-of-bounds access. amdgpu_vm_flush reads isolation->spearhead and enforce_isolation reads spearhead/owner/sync fence objects, which can disclose kernel pointers; CNA guidance scores OOB reads High unless limited to a few bytes.

I:HIntegrity impact, high

For GFX/compute rings, amdgpu_device_enforce_isolation writes isolation->spearhead, owner, and amdgpu_sync hash tables at the OOB address and dma_fence_put()s a wild fence pointer, which is an out-of-bounds write and UAF/control-flow primitive scored High.

A:HAvailability impact, high

The ~0 index yields a wildly invalid pointer whose dereference oopses the host, and UBSAN array-index-out-of-bounds aborts under CONFIG_UBSAN_TRAP or panic_on_warn. Either outcome is a kernel crash that fully denies GPU/host availability.