Cloudanix VulnDB

CVE-2026-98144

None

CVSS

—

EPSS

0.1%

Published

Sep 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's AMD accelerator driver can slowly leak memory when certain unusual operations are performed with buffer handles.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Other
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Reference count leak in amdxdna_cmd_set_error when BO mapping fails after handle reuse and dma-buf import without vmap support, leaving an elevated refcount on the object.

Why it matters to the business

Long-term kernel memory pressure or eventual resource exhaustion on systems using the amdxdna accelerator driver; limited real-world exposure reduces immediate operational risk but still requires patching.

How an attack unfolds

An attacker crafts userspace sequences that submit a command chain, close the original handle, then import a dma-buf lacking vmap support onto the recycled id; when the driver later resolves the handle and fails to map, the missing put leaks the reference.

How to fix it

Update the Linux kernel to a version containing the fix that ensures the put occurs on all error paths in amdxdna_cmd_set_error; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the patch is present by inspecting the amdxdna_cmd_set_error function for balanced get/put on the first BO of the chain; test with reproducer sequences that close handles and import non-vmap dma-bufs.

Typical attack path

  1. Submit command chain via amdxdna ioctl
  2. Close original BO handle after submission
  3. Import incompatible dma-buf onto recycled handle id
  4. Trigger amdxdna_cmd_set_error path that resolves the BO
  5. Mapping failure occurs and reference is not released

How to detect it

Review kernel logs for repeated amdxdna BO mapping failures or reference count warnings; inspect userspace code or traces showing handle close immediately after command submission followed by dma-buf import on the same id.

What your security team should do

  • Prioritize kernel updates on systems exposing /dev/accel or using AMD XDNA hardware
  • Monitor for amdxdna-related oops or memory leak reports in dmesg
  • Restrict unprivileged access to accelerator device nodes until patched

The record

In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: put the chained BO when its mapping fails amdxdna_cmd_set_error() looks up the first BO of a command chain, which takes a reference, and drops it at the end of the function. The mapping of that BO is established in between, and the failure path returns without the put, so the reference is leaked. Ordinary use does not reach it. The chain has been submitted before any of this runs, so aie2_cmdlist_fill_slot() has already called amdxdna_cmd_get_op() on that BO and amdxdna_gem_vmap() has cached its address. What makes it reachable is that the BO is resolved again by handle here, and the handle is userspace's to recycle: closing it after submission and importing a dma-buf whose exporter implements no vmap onto the same id leaves amdxdna_gem_get_obj() returning an object this cannot map, since prime_import() types every import AMDXDNA_BO_SHARE.

Affected packages

Ecosystem Package Introduced Fixed