CVE-2025-37769: AMD SMU11 Division by Zero Crashes Linux Kernel

A recently disclosed vulnerability in the Linux kernel’s AMD DRM power-management code — tracked as CVE-2025-37769 — allows a carefully crafted input to trigger a division-by-zero inside the SMU11 power-management path, causing kernel crashes and sustained denial-of-service on affected systems.

Background​

The Linux kernel’s Direct Rendering Manager (DRM) subsystem contains the amdgpu driver family that manages AMD GPUs and their power-management firmware interface (SMU, System Management Unit). In early 2025 security researchers using static-analysis tooling identified an unchecked arithmetic condition in the SMU11-specific power-management code path: a user-controllable “speed” value can be set high enough that a subsequent calculation produces a zero denominator. The practical result is a kernel oops or panic when that arithmetic is executed, producing a local denial-of-service (DoS) that can be triggered repeatedly or sustained while an attacker supplies the malformed input.
This is not an abstract bug: the SMU interfaces are part of the kernel driver used on numerous modern AMD GPUs and in many Linux distributions’ kernels. The vulnerability was fixed in kernel trees via a patch that adds proper validation and prevents the division by zero from occurring; distributions have since begun shipping those fixes in their kernel security updates.

---

Overview of the flaw​

What goes wrong, in plain terms​

At a high level, the driver accepts a speed parameter — intended to represent a performance or power-management setting — and later uses that value in a computation. Because the code uses unsigned integer arithmetic and does not validate the full range of input values, values above a certain threshold (effectively greater than UINT_MAX divided by 8 in the observed fixes) can cause the computed denominator to become zero.
When kernel code performs a division by zero, the CPU generates a fault that the kernel translates into an oops or panic. That fault generally crashes the thread executing the division and may take down the entire kernel or render driver functionality unusable until a reboot or module reload, creating an availability-impacting condition.

Why this matters beyond a single crash​

• GPU drivers run in kernel space, so a crash in driver code is a kernel-level crash — not just a user-space process fault.
• Many cloud, workstation, and server environments now expose GPU resources to multiple tenants, containers, or user accounts. A relatively low-privilege user who can interact with the driver can cause an outsized operational impact.
• Even where a crash is non-fatal to the entire system, repeated triggering can create persistent disruption to graphical sessions, compute workloads, or any service that relies on GPU acceleration.

---

Technical analysis​

The vulnerable code path (conceptual)​

The vulnerability sits in the SMU11-specific files under drivers/gpu/drm/amd/pm (the AMD power-management code for SMU11-class SoCs and GPUs). The generic sequence is:

• User or process sets a speed/profile parameter exposed by driver interfaces (sysfs, ioctl, or another control path).
• The driver accepts the value without a guard limiting the top end.
• Later, the code computes a divisor derived from that speed value and other internal constants.
• Because the check for an out-of-range speed is missing, the computed value can wrap or evaluate to zero.
• The kernel performs a division with that zero denominator and the CPU traps, producing an oops or panic.

Why unsigned arithmetic matters​

Unsigned integer wrapping and arithmetic rules in C mean that operations near UINT_MAX are dangerous when code performs arithmetic that assumes non-wrapping behavior. A simple calculation that divides by (UINT_MAX - some_value) or multiplies then divides by a factor, without explicit bounds checking, can inadvertently produce zero. The fix applied in the kernel patches explicitly validates the speed input and rearranges calculations to avoid zero denominators.

Attack surface and privileges​

The public disclosures indicate that the problematic input originates from a user-settable speed value; that implies the interface to set the value is reachable from user context. The practical privilege required depends on how the distribution or system exposes GPU controls:

• If the driver exposes sysfs entries or ioctls that are writable by unprivileged users or containerized workloads with access to /dev/dri, an unprivileged user can trigger the condition.
• On many systems, GPU device nodes and control interfaces are restricted (e.g., owned by root or a gpu group), increasing the privilege required to exploit the bug.
• In multi-tenant or container environments where GPU devices are passed through or device access is granted by profile, the ability to set driver parameters makes exploitation possible from lower privileges.

Because of variability in how distributions and admins configure device permissions, the practical exploit vector ranges from local unprivileged users (in permissive setups) to local administrators in stricter environments.

---

Impact assessment​

Availability impact​

This CVE is an availability issue — a division-by-zero kernel fault that leads to an oops, driver failure, or system crash. The consequences vary by deployment:

• Desktop/workstation: display manager or desktop environment can crash; user session may be disrupted and system may require a reboot.
• Servers with GPU compute: jobs using the GPU may be terminated; the compute node may require manual intervention or reboot.
• Cloud/multi-tenant infrastructure: if attackers controlling a tenant can trigger the bug, they can deny GPU resources to other tenants or cause instability in shared compute nodes.

Confidentiality and integrity​

There is no public evidence the flaw gives rise to information disclosure or privilege escalation in the wild; the direct consequence is a DoS condition. That said, kernel crashes can complicate incident response and may open secondary risks on systems with fragile recovery setups.

Exploitability and complexity​

The vulnerability’s exploitation complexity is low to moderate depending on the environment:

• Low complexity where the interface is writable by an attacker (e.g., permissive sysfs permissions or container access to device nodes).
• Moderate complexity where additional steps are required to access or craft the specific speed value or where the attacker must manipulate workloads to reach the vulnerable code path.

The core arithmetic condition makes exploitation deterministic when the input criteria are met, increasing the practical risk in permissive setups.

---

Which systems are affected​

Affected code resides in the Linux kernel’s AMD DRM SMU11 power-management code and therefore impacts kernels that include the vulnerable commit range prior to patching. The practical set of affected machines includes systems that:

• Use AMD GPUs that rely on the SMU11 code paths (SMU11 corresponds to AMD GPU families implemented in the driver’s smu11 backend — several modern AMD SoCs and GPUs use that code).
• Run kernel versions that have not yet received the backported fix from kernel stable branches or their distribution’s security update.

Because distributions often backport fixes to long-term kernels, the presence or absence of the fix depends on each distro’s security update cycle and the installed kernel package. Administrators should assume a system is vulnerable until the kernel has an explicitly applied fix.

---

Mitigation and remediation​

Immediate actions for administrators​

• Apply vendor and distribution kernel security updates immediately. The definitive remediation is an updated kernel that contains the patch for the SMU11 division-by-zero. Prioritize machines providing GPU resources to multiple users or containers.
• Reboot if required. Kernel fixes typically require a reboot to take effect; plan maintenance windows and apply updates as soon as feasible.
• Restrict access to GPU device nodes and driver interfaces. Until patched, limit who can write to sysfs entries or access /dev/dri:
• Ensure /dev/dri/* device nodes are owned by root:root or a limited group.
• Use group membership (e.g., a gpu group) to tightly control which accounts may access GPU devices.
• Harden container and virtualization GPU access. Avoid passing host device access directly into untrusted containers. Use device plugins and strict RBAC, or provide GPU access only through vetted device drivers and management layers.
• Unbind the driver or unload the module (short-term, disruptive). If a node is critical and immediate update isn’t possible, consider removing driver access:
• Unload the amdgpu module (modprobe -r amdgpu) — note this will terminate graphic sessions and GPU jobs.
• Bind GPU devices to vfio or other safe backends if applicable; this is an advanced and disruptive step.

Longer-term recommendations for operators​

• Implement least-privilege access for device nodes and driver configurable parameters.
• Monitor dmesg and kernel logs for oopses, “divide error”, or amdgpu stack traces; integrate these alerts into centralized logging.
• Maintain a timely kernel update cadence for nodes that provide shared acceleration resources.
• Employ “canaries” in multi-tenant GPU clusters: periodic synthetic jobs that exercise driver paths and detect abnormal behavior before tenants are impacted.

---

Detection and incident response​

What to look for in logs​

• Kernel messages containing phrases like “divide error” or “division by zero”.
• amdgpu-specific stack traces or messages immediately preceding a crash.
• Repeated kernel oopses or watchdog-triggered reboots correlated with GPU workload submission times.
• Unexpected termination of GPU-accelerated jobs, graphical session crashes, or long-term GPU unavailability.

Triage steps​

• Collect dmesg and kernel logs from the affected machine; preserve logs for forensics.
• Identify which process or user wrote to driver interfaces just before the crash.
• If reproducible, attempt to capture the exact input values (speed parameters) used; this helps confirm the trigger and assists maintainers in patch verification.
• Patch and reboot the node as the primary remediation.
• If the system cannot be patched immediately, isolate it from untrusted workloads until remediation is complete.

---

Why this class of bug keeps occurring (developer perspective)​

Division-by-zero and integer-overflow classes of errors remain common in low-level code for a few reasons:

• Kernel and driver code often uses performance-optimized integer arithmetic and bitwise operations; safety checks are sometimes omitted for speed or because the original assumptions about valid input ranges are violated over time.
• Driver code interfaces evolve; values that were once settable only by privileged tools can be exposed indirectly through user-space frameworks, increasing the range of inputs the code must now tolerate.
• Static analysis tools catch many of these problems, but not all maintainers run the same suite or act on every finding immediately; backporting to stable kernels adds another layer of complexity.
• Hardware vendor-specific code paths (multiple flavors of SMU, generation-specific tweaks) increase code complexity and create many subtly different places where similar checks must be applied.

For driver developers, the fix patterns are straightforward: validate user inputs for ranges that prevent arithmetic anomalies, use safe integer helper functions, and prefer early fail-fast checks rather than assuming values cannot reach edge cases.

---

Code hygiene and recommended developer fixes​

For maintainers and driver authors, the following patterns reduce the chance of similar defects:

• Validate inputs at the API boundary. Every user-provided value should be checked for explicit minimum and maximum allowable ranges before being used in arithmetic that could produce a zero denominator or wrap.
• Use safe arithmetic helpers. Helper macros or functions that detect overflow/wrap (e.g., checking multiplication or addition against maximums) eliminate implicit unsigned wrap surprises.
• Avoid computed denominators when possible. If a division uses a computed denominator, ensure the denominator is tested for zero before performing the division and provide deterministic fallback behavior.
• Unit tests and fuzzing. Add unit tests that feed extreme values into sysfs/ioctl paths and GPU control interfaces, and run targeted fuzzing against user-exposed code paths to catch boundary conditions.
• Static analysis integration. Enforce static-analysis checks in CI pipelines and treat SVACE/coverity findings as actionable; regressions in code hygiene should fail merges until resolved.
• Consistent error handling. If a runtime condition would produce an invalid state, the driver should return a standard error and not attempt the unsafe calculation.

---

Practical guidance for administrators and cloud providers​

• Treat any GPU resource exposed to tenants or untrusted users as a potential attack surface. The ability to crash kernel-level drivers creates a unique low-cost denial-of-service vector.
• For multi-tenant GPU clusters, apply strict device whitelisting via cgroups and container runtimes. Use Kubernetes device plugins that enforce access policies, and consider per-tenant allocation nodes to reduce blast radius.
• Maintain a kernel and driver inventory: know which nodes use which GPU families and which kernel versions they run. Prioritize patching nodes that run SMU11-capable GPUs.
• Automate kernel update testing where feasible: automated reboot and smoke tests for GPU functionality can help ensure patches do not break workloads in production.
• For virtualized environments, avoid exposing raw device nodes to guest VMs unless necessary; use mediated passthrough or virtualized devices when possible.

---

Strengths in the response ecosystem — and remaining risks​

The good news is that this class of bug is relatively well understood and straightforward to remediate: a guard check and small code change eliminate the division-by-zero, and upstream kernel and major distributions have already integrated fixes. Static analysis tools (like the one that discovered this issue) and the kernel stable maintenance process continue to find and patch these problems rapidly.
That said, residual risk remains:

• Some long-term or heavily customized kernels may not receive backports promptly, leaving machines vulnerable even after a public fix exists.
• Systems exposing GPU control to containers, CI jobs, or untrusted users remain at high risk until configuration hardening is applied.
• Operational disruption from applying kernel patches and reboots is often the limiting factor in patch adoption for critical systems, which increases dwell time for the vulnerability.

Administrators must balance operational constraints against the high availability risks posed by kernel-level DoS vectors.

---

A short checklist for immediate action​

• Inventory systems with AMD GPUs and identify kernel versions.
• Check distribution security advisories and apply the kernel update that includes the SMU11 fix.
• Reboot updated nodes and verify GPU functionality with representative workloads.
• Restrict write permissions to GPU control interfaces and device nodes.
• Add log monitoring for kernel “divide error” or amdgpu oops traces and alert on anomalies.
• For cloud providers: isolate GPU-hosting nodes from user-accessible consoles until patched.

---

Conclusion​

CVE-2025-37769 is an instructive example of how a small arithmetic validation omission in kernel driver code can have outsized operational consequences. The bug — a division-by-zero in the SMU11 path of the AMD DRM power-management code — produces kernel-level crashes and denial-of-service, and it can be triggered by user-supplied values when driver interfaces are reachable. Fortunately, the root cause is trivial to fix and upstream patches are available, but real-world risk depends on how quickly organizations apply those patches and how strictly they control access to GPU devices.
For administrators and operators, the takeaways are clear: patch promptly, restrict access to GPU device interfaces, and bake input validation and static-analysis tooling into the development lifecycle to avoid future surprises. For driver authors, the vulnerability reinforces the importance of defensive programming at API boundaries and automated checks that catch edge-case arithmetic errors before they reach production systems.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center