CVE-2026-23338: drm/amdgpu/userq: Do not allow userspace to trivially triger kernel warnings
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/userq: Do not allow userspace to trivially triger kernel warnings
Userspace can either deliberately pass in the too small num_fences, or the
required number can legitimately grow between the two calls to the userq
wait ioctl. In both cases we do not want the emit the kernel warning
backtrace since nothing is wrong with the kernel and userspace will simply
get an errno reported back. So lets simply drop the WARN_ONs.
(cherry picked from commit 2c333ea579de6cc20ea7bc50e9595ef72863e65c)
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue lets userspace trigger AMDGPU kernel warning backtraces through the userq wait ioctl. The sources describe an erroneous warning path, not direct privilege escalation or data exposure. The practical concern is operational noise, log pressure, or alert fatigue on affected AMD GPU systems.
Executive priority
Treat as a low-priority kernel maintenance issue unless affected AMD GPU hosts show log flooding or operational instability. Fold remediation into normal kernel patch cycles, with faster handling for shared GPU infrastructure.
Technical view
In drm/amdgpu/userq, userspace can provide too small num_fences, or the required fence count can grow between ioctl calls. Existing WARN_ON checks emitted kernel backtraces even though the kernel was not in an invalid state. Stable commits remove those warnings and return errno to userspace.
Likely exposure
Exposure is most likely on Linux systems running affected kernel versions with AMDGPU user queue functionality available to local userspace. The provided data lists Linux kernel versions around 6.16, 6.18.17, 6.19.7, and 7.0 as affected, but distribution mapping must be confirmed by vendor advisories.
Exploitation context
The bundle does not show KEV listing, active exploitation, public exploit code, or remote attack evidence. The described trigger is local userspace interaction with an AMDGPU ioctl that can cause kernel warning backtraces, not a confirmed compromise path.
Researcher notes
The CVE record lacks CVSS, CWE, and detailed distribution impact. Analysis is limited to the kernel description and stable commit references. The change removes WARN_ON behavior; it does not identify a memory safety issue or privilege boundary bypass.
Mitigation direction
Apply Linux kernel updates containing the referenced stable fixes.
Prioritize shared AMD GPU hosts and GPU compute environments.
Check distribution vendor advisories for exact patched package versions.
Monitor kernel logs for repeated AMDGPU userq warning backtraces.
Validation and detection
Inventory Linux hosts using AMDGPU drivers and local GPU workloads.
Compare running kernel versions against vendor-patched releases.
Review kernel logs for recurring amdgpu userq wait ioctl warnings.
Confirm stable commits are included in deployed kernel source or packages.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23338 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Mar 25, 2026, 10:27 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.