CVE-2026-46220
Kernel Panic in AMDGPU SDMA4 Fence Emission
Publication date: 2026-05-28
Last updated on: 2026-05-28
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the Linux kernel's AMDGPU driver, specifically in the sdma4 component. The function sdma_v4_0_ring_emit_fence() contains two BUG_ON assertions that check if fence writeback addresses are properly dword-aligned. These assertions can be triggered by unprivileged userspace through crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread.
The fix replaces these BUG_ON calls with WARN_ON calls, which log the issue without crashing the kernel. The problem arises because the assertions are reachable from userspace, and crashing the kernel is not an appropriate response. The vulnerability highlights that invalid submissions should be filtered earlier in the IOCTL path rather than at the ring emission callback stage.
How can this vulnerability impact me? :
This vulnerability can cause a fatal kernel panic triggered by unprivileged userspace processes submitting crafted commands. This results in a denial of service (DoS) condition where the system crashes unexpectedly, potentially disrupting normal operations and requiring a reboot.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability causes a fatal kernel panic in a scheduler worker thread when triggered by crafted DRM_IOCTL_AMDGPU_CS submissions from unprivileged userspace. Detection can involve monitoring system logs for kernel panic messages related to the amdgpu driver or fence writeback address alignment issues.
Since the vulnerability is triggered by specific IOCTL calls, you can check for abnormal or suspicious DRM_IOCTL_AMDGPU_CS ioctl calls using tools like auditd or strace on processes interacting with the amdgpu driver.
- Use dmesg or journalctl to look for kernel warnings or panics related to amdgpu or fence emission.
- Use auditctl to monitor ioctl calls to the amdgpu device, for example: auditctl -a exit,always -F arch=b64 -S ioctl -F a0=<amdgpu_device_fd>
- Use strace on suspect processes to trace DRM_IOCTL_AMDGPU_CS ioctl calls.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability has been resolved by replacing BUG_ON assertions with WARN_ON in the Linux kernel amdgpu driver, preventing kernel crashes while logging the issue.
Immediate mitigation steps include updating the Linux kernel to a version that includes this fix.
Additionally, restricting unprivileged userspace access to the amdgpu DRM device or filtering invalid DRM_IOCTL_AMDGPU_CS submissions at the CS IOCTL path can help prevent exploitation.
- Update the Linux kernel to a patched version that includes the fix for this vulnerability.
- Restrict access permissions to the amdgpu DRM device to trusted users only.
- Monitor and filter invalid or suspicious DRM_IOCTL_AMDGPU_CS ioctl submissions if possible.