CVE-2025-37852 Fix Prevents Linux AMDGPU Kernel Crashes

The practical action is straightforward for Linux systems using the in-kernel

driver: deploy the vendor kernel update rather than attempting to extract this one five-line patch. The Linux kernel project explicitly advises against cherry-picking individual stable fixes, and the relevant distribution package may already include the correction under a vendor-specific build number.

This CVE does not describe a flaw in AMD’s Windows display driver or AMD Software: Adrenalin Edition. It is in the Linux kernel file

, which is used by the kernel’s AMDGPU PowerPlay code. Windows users need to care only where they administer Linux on AMD hardware—dual-boot machines, Linux workstations, servers with AMD GPUs, virtual-host environments, or distributions used alongside Windows endpoints.

The failure path was small, but it ran in kernel space​

The upstream patch, authored by Wentao Liang and accepted with AMD maintainer Alex Deucher’s sign-off, adds a check immediately after

calls

. Before the fix, the function stored the returned device pointer in the hardware-manager structure and continued initialization even if the helper had failed.

The repaired path checks whether

is null. If it is, the kernel frees the already allocated

structure and returns

, the conventional error for an allocation or resource-creation failure. That prevents later PowerPlay initialization code from dereferencing a null device pointer.

The coding change is only five added lines, but its placement matters. A null pointer dereference in a graphics driver is not an ordinary application crash: it can take down the kernel or leave the GPU driver in a reset-recovery loop. NVD classifies the weakness as CWE-476, a null pointer dereference, and assigns CVSS 3.1 score 5.5, Medium, with local access, low attack complexity, low privileges required, no user interaction, and high availability impact.

The record does not document a public proof of concept, a demonstrated privilege-escalation chain, or a remotely reachable trigger. Its consequence is a potential denial of service under the circumstances in which the AMDGPU Common Graphics Services device-creation helper fails. That narrower technical picture is important: this is a legitimate kernel security fix, but the available primary material does not support treating it as an internet-exposed AMD GPU takeover.

Linux 6.15 contains the upstream repair; stable branches received backports​

The Linux CVE announcement lists the upstream fix as commit

, included in Linux 6.15-rc1. The stable tree subsequently carried equivalent fixes into the maintained branches available at the time:

The key operational detail is that this is not a simple “anything below 6.15 is vulnerable” case. A server running Linux 6.1.135 or later, for example, is protected even though its kernel’s headline version is far below 6.15. Conversely, an unpatched 6.1.134 kernel is within the affected range despite being on an LTS series.

The Linux CVE announcement also identifies the relevant source file and says individual commits are neither tested nor supported in isolation. That reflects how stable kernel releases are validated: a backport arrives with a collection of other fixes, configuration changes, and regression testing. For administrators, the right comparison is between the installed distribution kernel package and the distribution’s declared fixed build, not merely the

major and minor number.

Debian’s package record shows why kernel version alone can mislead​

Debian’s security tracker confirms the fix in its current package streams, but it also illustrates why distributions cannot be assessed from upstream version labels alone. Debian identifies

6.1.135-1 as the fixed source package for Bookworm and

6.1.137-1~deb11u1 for the Bullseye LTS backport package. Its current tracker lists Bookworm, Trixie, Forky, and Sid package builds as fixed.

The same tracker retains a vulnerable status for Debian Bullseye’s older

5.10 package line, including the 5.10.259-1 security build. That is not a contradiction with the upstream table. It means Debian’s 5.10 package stream did not receive this particular backport, while Debian’s separately maintained 6.1 kernel package for Bullseye did.

For fleet operators, that produces a concrete checklist:

• Systems booting a distribution-maintained 6.1, 6.6, 6.12, 6.13, 6.14, or newer kernel should be checked against the distribution’s fixed package advisory, not against the generic upstream branch number alone.
• Long-lived 5.10 deployments require extra scrutiny because a supported distribution may choose not to backport every upstream fix to every kernel flavor.
• Self-built kernels based on code before the upstream 6.15-rc1 merge need the patch or a later stable backport, unless the maintainer can verify that an equivalent downstream fix was already applied.
• Immutable images, appliance kernels, GPU compute nodes, and custom cloud images should be audited separately because they frequently lag their parent distribution’s current repository kernel.

Oracle Linux also recorded the CVE and associated it with later UEK errata for Oracle Linux 9 and 10, an additional confirmation that downstream vendors treated the issue as a kernel maintenance item rather than as an AMD Windows driver advisory.

NVD’s CPE display is incomplete-looking, but the record is not missing platform data​

The NVD page currently shows the familiar “CPEs loading” placeholder in its interactive configuration area, followed by a prompt asking whether a CPE is missing. Read literally, that presentation can suggest the CVE has not yet been mapped to affected software. Its own change history says otherwise.

NVD added CPE configuration data on November 17, 2025. The entries cover the generic Linux kernel through the fixed stable releases and include a Debian Linux 11 mapping. The June 17, 2026 kernel.org update went further, adding a source-code-oriented affected statement: Linux is affected beginning with version 4.17, subject to the listed fixed stable releases and the upstream fix in Linux 6.15.

So the answer to the visible prompt is: no additional generic Linux-kernel CPE appears necessary merely because the widget has not rendered its configuration list. The CPE data exists in the NVD record history, and the newer kernel.org metadata provides a more precise way to model this kind of issue: affected commit ranges and explicit fixed commits.

There is still a meaningful limitation. CPEs identify products and version bands, but they do not reliably answer whether a distribution shipped a backport. A distro can report a fixed package while retaining an upstream-looking version number, or it can continue a kernel line without this exact patch. Security scanners that report this CVE solely from a generic

CPE can therefore produce false positives or false negatives unless they ingest vendor errata and package-level status.

The date change is metadata maintenance, not a fresh emergency​

The most consequential discrepancy in this record is temporal. NVD says the CVE was published on May 9, 2025, while the page was last modified on June 17, 2026. The August 11, 2026 publication timestamp attached to the submitted entry appears to reflect a later feed or database publication event, not the original disclosure or fix date.

That distinction should affect triage. CVE-2025-37852 deserves remediation where an affected AMDGPU PowerPlay kernel is still deployed, particularly on systems where a GPU-driver crash would interrupt compute, desktop, or graphics workloads. But it is a mature, backported kernel reliability and availability fix, not evidence of a newly exposed AMDGPU zero-day.

Administrators should close the issue by updating to their distribution’s current supported kernel and rebooting into it. On Debian-family systems, the installed package version—not just the running kernel’s

prefix—will determine whether the backport is present; on custom images, the upstream commit and the six stable backports provide the definitive code-level comparison.