Cloudanix VulnDB

CVE-2026-98145

None

CVSS

—

EPSS

0.1%

Published

Sep 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux graphics driver code lets local programs send a malformed request that can crash the whole computer.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Improper validation of command chains with zero command_count allows submission of a zero-length buffer to firmware, triggering an out-of-bounds read in drm_clflush_virt_range on certain firmware paths and causing a kernel fault.

Why it matters to the business

Local users with access to the GPU render node can crash the system, leading to denial of service on affected Linux systems running the amdxdna driver; low exploitability and no known active campaigns reduce immediate risk.

How an attack unfolds

An attacker opens the render node, crafts an EXEC_CMD ioctl with a command chain header indicating zero commands, and submits it; the missing validation allows the zero-length submission to reach firmware handling that performs an invalid memory access, crashing the kernel.

How to fix it

Update to a Linux kernel containing the fix that rejects zero-command chains in accel/amdxdna before submission; apply the patch that adds the early rejection of empty command_count requests.

How to confirm the fix worked

Confirm the presence of the upstream commit that adds the zero command_count rejection check in accel/amdxdna; test that ioctl submissions with command_count=0 are rejected with an error rather than proceeding to firmware submission.

Typical attack path

  1. Obtain access to a user account on a system with the vulnerable amdxdna driver loaded
  2. Open the DRM render node device file
  3. Construct and submit an EXEC_CMD ioctl containing a command chain with command_count set to zero
  4. Trigger the firmware submission path that performs the invalid clflush operation

How to detect it

Review kernel logs for amdxdna submission paths and drm_clflush_virt_range faults with zero-length buffers; inspect audit logs for unusual EXEC_CMD ioctls from non-privileged processes on render nodes.

What your security team should do

  • Prioritize kernel updates on systems exposing the amdxdna render node to untrusted users
  • Restrict access to /dev/dri/renderD* nodes via group permissions or SELinux policies until patched
  • Monitor kernel logs for amdxdna and drm_clflush related faults on unpatched systems

The record

In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: reject a command chain that carries no commands A chain whose command_count is zero passes the payload length check, because struct_size(payload, data, 0) is just the header. The fill loop then does not run, so offset stays zero and the request is submitted with a zero-length buffer. On firmware without AIE2_NPU_COMMAND that ends at the opcode check, since op is still ERT_INVALID_CMD and aie2_get_chain_msg_op() answers MSG_OP_MAX_OPCODE. aie2_get_npu_chain_msg_op() answers MSG_OP_CHAIN_EXEC_NPU whatever it is given, so there the submission continues to drm_clflush_virt_range(cmd_buf, 0), which reads the byte before the buffer and faults on the vmap guard page. EXEC_CMD is reachable by any process that can open the render node. Reject the request instead.

Affected packages

Ecosystem Package Introduced Fixed