CVE-2025-37853 Fix Blocks Linux AMDGPU MES Kernel Crashes

The timing needs clearing up. Although the supplied feed is dated August 11, 2026, the Linux CNA published CVE-2025-37853 on May 9, 2025. NVD initially analyzed it on November 17, 2025 and updated its affected-version metadata again on June 17, 2026. This is therefore a record update or resurfaced advisory, not a newly disclosed AMD GPU kernel flaw.

NVD assigns a CVSS 3.1 score of 5.5, Medium, with local access, low complexity, low privileges, no user interaction, and high availability impact. That rating describes the possibility of a kernel crash; it does not establish data exposure, privilege escalation, or remote code execution.

The crash sits behind a deliberate GPU-reset test​

The vulnerable path is in

, part of the AMD Kernel Fusion Driver subsystem used for AMD GPU compute. The relevant debugfs entry,

, exists to deliberately hang the hardware scheduler, or HWS, so developers can exercise GPU-reset recovery.

That is an unusually important qualifier. This was not a defect reached while rendering a game, watching video, or merely running an AMD Radeon system. The caller must reach a debug interface, provide a GPU ID, and select a device on the affected compute path. The interface is named

because its intended effect is to provoke a GPU hang.

Linux kernel documentation describes debugfs as a developer-facing filesystem with no stable user-space ABI guarantee. It is normally mounted at

, and its root is accessible only to root by default. The KFD implementation creates

as a write-only file with owner-write permissions under the

debugfs directory. Administrators can alter debugfs mount ownership and permission options, however, so “normally root-only” is not the same as “inaccessible on every deployment.”

The CVSS low-privileges rating should consequently be read as an exposure model, not a promise that every ordinary desktop user can trigger it. On a conventional distribution installation with default debugfs permissions, an unprivileged local account will not be able to write to the file. A system where debug controls have been intentionally delegated, exposed through a lab automation arrangement, or made accessible inside a privileged container deserves a closer look.

MES takes a different scheduling path​

The root cause is specific and mundane: the HWS hang-test code assumes the device queue manager has a configured

object. On the MES path, it does not. MES is AMD’s firmware-assisted scheduling route, and the KFD debug hook was not implemented to use it.

Before the patch, the test called into the HWS hang routine anyway. That led to a NULL pointer dereference when the code reached the unavailable packet manager. The Linux CNA description says the outcome is a kernel crash, which aligns with NVD’s availability-only impact rating.

The fix is five lines, but its consequence is more meaningful than the size suggests. The patched

routine now checks whether MES is enabled. If it is, the driver logs that inducing an MES hang is unsupported and returns

; it never calls the legacy HWS test machinery.

In other words, the patch does not add a working MES reset-test facility. It disables the unsupported MES use case while retaining the existing HWS test behavior for non-MES GPUs. The upstream commit message explicitly says a MES-capable

debugfs interface may be supported later. As of the code currently published in the Linux tree, that later support is still not part of this fix.

That distinction matters for GPU validation teams. Updating closes the crash path, but any script that expects to use

to test reset recovery on MES-enabled hardware will now fail by design. Treat that failure as confirmation that the safeguard is active, not as a driver regression to work around.

Fixed kernel versions depend on the maintained branch​

The upstream change landed in the Linux 6.15 development cycle, with the mainline commit included in Linux 6.15. Kernel stable maintainers also backported it to the branches then receiving the fix. The Linux CNA’s affected-version record identifies these fixed points:

• Linux 6.6 is fixed in 6.6.88.
• Linux 6.12 is fixed in 6.12.24.
• Linux 6.13 is fixed in 6.13.12.
• Linux 6.14 is fixed in 6.14.3.
• Mainline is fixed from Linux 6.15 onward.

The stable changelogs independently list the patch in Linux 6.12.24 and Linux 6.13.12, while the DRM pull request for Linux 6.15-rc1 includes the same AMD KFD change. Debian’s security tracker also records the mainline commit as arriving in 6.15-rc1 and lists its package-level remediation separately.

Do not use only

as a final vulnerability decision on an enterprise distribution. Linux vendors regularly backport a patch into a kernel whose visible base version is older than the upstream release that first carried it. Debian, Ubuntu, SUSE, Red Hat-derived distributions, appliance vendors, and cloud-image maintainers may all ship a fixed package with a version string that does not resemble 6.6.88, 6.12.24, 6.13.12, or 6.14.3.

Ubuntu’s tracker illustrates why package-level status is necessary. Its page evaluates many distinct Ubuntu kernel packages and hardware-enablements rather than issuing one blanket verdict for every release name. Some packages are marked fixed, some vulnerable, some not affected because the relevant code was not shipped, and others need evaluation. The distribution package advisory, not an upstream version comparison alone, is the operational record to use.

The broad Linux CPE is not enough to determine exposure​

NVD’s generic Linux kernel CPE is not missing so much as incapable of expressing the real prerequisites. A CPE can identify Linux kernel version ranges; it cannot adequately say “only when AMDGPU and AMDKFD are present, debugfs is built and mounted, the KFD debug endpoint is reachable for writing, hardware scheduling is selected, and MES is enabled.”

That limitation leads to a potentially misleading inventory result. A scanner can correctly flag a kernel version as falling within an affected upstream range while the installed system lacks an AMD GPU, has no KFD driver, omits

, leaves debugfs unmounted, or has no accessible MES-enabled GPU compute device. Conversely, a version-only scanner can miss a vendor backport that already inserted the reject-on-MES check.

The CVE record’s history also shows why readers should not confuse the database’s generic applicability data with an exploitability finding. NVD categorized the weakness as CWE-476, NULL Pointer Dereference, and supplied the availability-focused CVSS vector. Neither NVD nor the Linux CNA describes a privilege-escalation technique, information leak, remote attack path, or public exploit. No independent reporting reviewed for this advisory establishes one.

For fleet managers, this should rank below remotely reachable kernel issues and local privilege-escalation bugs. It still belongs in normal kernel patch management because intentionally crashing a shared compute host can interrupt workloads and force a reboot, but it is not evidence that every AMD-based Linux workstation has a practical attacker-triggerable kernel panic.

WSL users should distinguish the Linux guest from Windows​

CVE-2025-37853 does not affect the Windows kernel, the Windows AMD display driver, or ordinary native Windows applications. It concerns Linux’s upstream

implementation and a Linux debugfs test endpoint.

WSL 2 uses a full Linux kernel, so it is reasonable to ask whether a Windows machine running Linux workloads inherits the issue. Microsoft documents GPU compute support in WSL, and WSL supports custom kernels. But the usual WSL GPU model is paravirtualized DirectX-based GPU access rather than a normal bare-metal AMDGPU/KFD stack exposing the

control. The affected sequence specifically depends on the Linux KFD debugfs interface and a MES-enabled AMD GPU path.

For standard WSL installations, there is no basis in the CVE record to treat this as a Windows host security issue. The group that should evaluate it is narrower: administrators running a custom WSL kernel or specialized GPU-compute arrangement that includes native AMDGPU/KFD support, enables debugfs, and exposes its write controls. Those systems should assess the actual kernel configuration and driver path rather than assuming that any WSL GPU acceleration equals exposure.

The immediate operational outcome is straightforward: patch the Linux kernel package according to the distribution’s advisory, avoid granting non-administrative write access to kernel debugfs, and do not attempt to validate the CVE by writing to

. On MES-enabled hardware, a fixed driver now rejects that command; on an unpatched system, the “test” can take the machine down with it.