Linux AMDGPU CVE-2025-38104: Mutex to Spinlock Fix for RLCG Register Access

A small but important kernel change — replacing a sleeping mutex with a non‑sleeping spinlock in the AMDGPU driver’s RLCG register access path — has been tracked as CVE‑2025‑38104 and fixed upstream to eliminate a priority‑inversion and invalid‑wait context that could trigger kernel oopses or denial‑of‑service in SR‑IOV and virtualized GPU deployments.

Background / Overview​

The vulnerability lives in the Linux kernel's AMDGPU DRM driver and concerns the RLCG (Radeon Link/Read/Clock Gate) register access path used when virtual functions (VFs) or fast code paths need to manipulate GPU registers. When the driver used a mutex in this hot path, callers that were already in a non‑sleepable context (for example while holding a spinlock or in certain kworker contexts) could attempt a blocking lock and hit the kernel’s “Invalid wait context” kernel BUG. Upstream maintainers replaced the mutex with a spinlock to ensure the register access path remains safe in non‑sleepable contexts and to avoid priority inversion where a low‑priority holder of a mutex prevents a high‑priority thread from progressing. This remediation has been recorded in public CVE entries and stable‑tree patch lists. Why this matters operationally: the bug is primarily an availability issue. Triggering the erroneous code path may cause kernel oopses, driver resets, or system instability — outcomes that are particularly critical for multi‑tenant hosts, GPU‑accelerated cloud instances, or any environment that exposes GPU device nodes to less‑trusted workloads. Trackers classify the issue as medium severity for typical deployments, but the real‑world priority should be driven by exposure (who can access /dev/dri and whether GPU passthrough or SR‑IOV is in use).

---

Technical anatomy: what went wrong​

The code path and the risk​

At the heart of the problem is the function stack that led to a sleeping lock being used in a context that must not sleep:

• User code or kernel workers call into amdgpu_sriov_wreg to write a register on a virtual function.
• That path invokes amdgpu_virt_rlcg_reg_rw, which previously attempted to acquire a mutex named rlcg_reg_lock.
• In certain call contexts — notably during fast TLB flush routines such as gmc_v11_0_flush_gpu_tlb — callers may already be holding spinlocks or be running in a worker context that cannot safely sleep.
• When that happens, the kernel detects an invalid wait attempt and emits a [ BUG: Invalid wait context ] oops in the log; the trace typically shows the failing amdgpu functions and the rlcg_reg_lock entry.

This is classic kernel lock‑context hygiene: kernel mutexes may sleep; spinlocks may not. Holding one while trying to acquire the other, or otherwise attempting to sleep in a non‑sleepable context, produces a hard kernel failure.

Why switching to a spinlock fixes it​

The upstream change switches the rlcg register lock from a mutex to a spinlock, ensuring that any code paths that cannot sleep will not attempt a blocking mutex acquisition. Because the RLCG register access is a very hot and short critical section (read/write a small set of hardware registers), a spinlock is an appropriate synchronization primitive — it provides bounded, non‑sleeping mutual exclusion, avoids priority inversion in the observed call stacks, and eliminates the “invalid wait context” root cause. The upstream commit implementing this change appears in the kernel stable queue and was authored by AMD maintainers as part of the amdgpu area fixes.

---

Evidence and upstream tracing​

Upstream and distribution trackers all document this precise mitigation and provide the patch metadata: the Linux stable patch discussion and mailing‑list posts include the upstream commit SHA and the exact description "Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV", and major distributions (Ubuntu, Debian, SUSE etc. have mapped the CVE and linked fixed kernel packages. NVD and OSV also record the CVE description and remediation status. Those independent trackers converge on the same diagnosis and remediation approach, giving strong confidence that the problem and fix are correctly identified. Practical traces from bug reports show the canonical symptom: kernel oops lines referencing kworker threads trying to lock &adev->virt.rlcg_reg_lock inside amdgpu_virt_rlcg_reg_rw and a backtrace leading back to gmc_v11_0_flush_gpu_tlb. That trace is why the maintainers judged a spinlock to be the correct fix — the offending path can be run with non‑sleepable preconditions.

---

Affected systems, exposure model and exploitability​

• Who is affected: Any Linux system that runs a kernel containing the relevant AMDGPU driver codepath and does not have the upstream fix or a vendor backport. Desktop, workstation and server kernels are all candidates; embedded or OEM kernels are the long‑tail risk because they may lag upstream and skip backports.
• Attack vector: Local. An attacker needs to be able to trigger the GPU driver via modesetting operations, device IOCTLs, or similar flows — for example via an untrusted container that has /dev/dri mounted, a local user who can talk to the display stack, or VM guests that interact with the hypervisor’s VF/VF‑passthrough. Because the vector is local and hardware‑specific, public exploit activity has not been widely documented; however, a DoS primitive in kernel space is straightforward to weaponize against shared hosts.
• Likelihood and impact: The vulnerability is easy to trigger on susceptible stacks and manifests as availability impact (kernel oops, driver reset, host instability). Because the bug does not directly expose secrets or execute arbitrary user code in kernel context by itself, the score is reflected as medium on many trackers — but practical risk for production multi‑tenant hosts is high because an attacker with access to device nodes can cause service disruption.

---

Mitigation and remediation (what administrators should do)​

Immediate actions are straightforward and prioritized by risk:

• Patch the kernel (highest priority)
• Install vendor/distribution kernel updates that include the upstream fix or backport, then reboot into the updated kernel. Many distributions listed the CVE and published fixed package versions; check your distro security tracker or vendor advisory and apply the recommended kernel update. Upstream commit metadata and stable‑tree backports show the change is present in newer stable branches.
• If you cannot patch immediately, reduce exposure (compensating controls)
• Restrict access to DRM device nodes: use udev rules or group membership to limit /dev/dri/* to trusted groups only.
• Remove /dev/dri from untrusted containers or CI runners; avoid exposing GPU devices to untrusted guests or workloads.
• Consider temporarily blacklisting the amdgpu module on systems where GPU functionality is non‑essential (note: this disables GPU acceleration and may break user sessions).
• Monitor and detect
• Add log rules to capture kernel oops messages, pageflip timeouts, amdgpu watchdog entries, and amdgpu‑related stack traces in dmesg/journalctl. Preserve oops traces for vendor debugging if you must triage an incident. Affected logs often contain clear traces mentioning amdgpu_virt_rlcg_reg_rw and rlcg_reg_lock.
• For embedded and vendor kernels
• Open a vendor support case and request a backport if you manage appliances, vendor images, or embedded devices (these commonly have longer update cycles). If you build your own kernels, cherry‑pick the upstream stable commit into your tree, rebuild, and smoke‑test on representative hardware.
• Validation after patching
• Reboot into the patched kernel and run representative display and GPU workloads, including modeset, hot‑plug, and VM passthrough tests where applicable. Maintain staged verification windows (24–72 hours) for intermittent issues. Confirm absence of previous oops traces.

---

How to detect whether you’re affected (quick checklist)​

• On each host:
• Run uname -r to check kernel version and compare with your distro’s fixed package versions.
• Check whether the amdgpu module is loaded: lsmod | grep amdgpu.
• Inspect /dev/dri/* and note ownership and permissions; devices that are world‑readable/writable or accessible to untrusted containers increase exposure.
• Scan dmesg and journalctl -k for amdgpu oopses, "[ BUG: Invalid wait context ]", or stack traces that include amdgpu_virt_rlcg_reg_rw and rlcg_reg_lock. Preserve logs when you see them.

---

Cross‑verification and vendor mapping​

Multiple independent sources corroborate the diagnosis and remediation:

• The Linux stable patch discussion and maintainer notes (upstream commit metadata and stable‑queue posts) document the commit and explain the lock‑replacement rationale.
• Distribution security trackers (Ubuntu, Debian, SUSE and others) list CVE‑2025‑38104 with details and fixed package mappings; these tracker entries are consistent with the upstream commit.
• National vulnerability feeds such as NVD and OSV reflect the same summary and link to distribution advisories.
• Internal operational notes and triage playbooks (compiled guidance for operators) provide actionable detection and mitigation steps tailored to administrators and multi‑tenant operators. Those internal guidance documents emphasize the long‑tail risk for vendor kernels and recommend immediate patching for exposed hosts.

Where public mapping is incomplete, exercise caution. For example, a vendor or cloud provider may have only partially enumerated which product images include the vulnerable kernel component; absence of an attestation for a particular product is not proof that it is unaffected. Operators should confirm at the package/changelog level or via vendor security advisories.

---

Critical analysis — strengths of the fix and residual risks​

Strengths​

• The upstream fix is surgical and low risk: swapping a mutex for a spinlock in a short register‑access critical section is a minimal change that reduces regression potential and simplifies backporting to stable kernels. This is why distributions were able to incorporate the change quickly.
• Multiple independent trackers (NVD, Ubuntu, Debian, OSV, and stable‑tree mailing lists) converge on the same technical narrative and remediation steps, increasing confidence in the fix and simplifying operational triage.

Residual and systemic risks​

• Vendor / embedded kernel lag: The greatest operational exposure is the long tail of vendor images, OEM appliances, and embedded devices that may not receive timely backports. These fleets often outlast desktop distributions’ update cycles and are where a CVE like this remains a practical problem for months or years. Administrators of such fleets must engage vendors for backports or plan rebuilds.
• Misconfiguration: Systems that intentionally expose /dev/dri to untrusted containers or allow unprivileged users into the video/render groups remain high risk until patched. Lock hygiene fixes do not reduce the need for proper isolation of device nodes.
• Detection blind spots: Not all environments capture persistent kernel ring logs or serial console output; missing oops traces complicate incident response. Preserve logs where possible and add monitoring for kernel oops signatures.

---

Recommended operational playbook (concise)​

• Inventory:
• Identify hosts with amdgpu loaded and /dev/dri exposed.
• Patch:
• Apply vendor/distribution kernel updates that include the stable commit; reboot hosts. Confirm package changelog references the CVE or the upstream commit.
• Compensate (if patching delayed):
• Restrict /dev/dri access; remove device nodes from untrusted containers; consider module blacklist where acceptable.
• Monitor:
• Create alerts for amdgpu oops, pageflip timeouts, and kernel BUG logs; preserve traces for vendor support.
• Vendor escalation:
• For embedded/OEM images, open support cases requesting backports or updated images if you cannot rebuild.
• Test and verify:
• After patching, run representative display workloads for 24–72 hours to ensure no regressions or recurrence.

---

Final assessment and takeaways​

CVE‑2025‑38104 is a textbook kernel robustness/locking‑context defect: a sleeping lock used in a non‑sleepable context, resulting in kernel BUGs and availability failures. The upstream response — replacing the mutex with a spinlock in the RLCG register access path — is technically sound for a short, hot register access critical section and has been accepted into stable kernel trees and vendor updates. Multiple independent trackers confirm the fix and map it into distribution packages. From an operational perspective, the pragmatic priority is clear: if you run AMD GPU drivers in an environment where untrusted or low‑privilege actors can access GPU device nodes (multi‑tenant servers, GPU‑accelerated cloud instances, or containers that mount /dev/dri), schedule the kernel update and reboot as soon as vendor packages are available. Where immediate patching is impossible, apply compensating controls (restrict device access, remove /dev/dri from untrusted containers, increase kernel oops monitoring) and engage vendors for backports on embedded or OEM images. Preserve kernel logs for forensics and validation after patching to ensure the regression is resolved.
Administrators and platform engineers should treat this CVE as a reminder that kernel‑space synchronization decisions are not just code hygiene — they’re operationally significant, especially in virtualized and multi‑tenant environments where a small blocking assumption can escalate directly into host‑level unavailability. Continued vigilance on vendor advisories, package changelogs, and kernel oops telemetry will keep your fleet resilient to this class of problems.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center