- The Linux kernel’s AMD GPU driver has a UBSAN shift-out-of-bounds vulnerability, known as CVE-2021-4460. This vulnerability is found in
kfd_device_queue_manager.cand affects kernel versions up to 5.4.117, 5.10.35, 5.11.19, and 5.12.2. - When
get_num_sdma_queuesorget_num_xgmi_sdma_queuesreturn zero, the bug is activated. This results in a bit-shift operation that goes against C’s undefined behavior rules and is identified by the UBSAN sanitizer. - This vulnerability has been given a rating of 5.8 by SUSE under CVSS 4.0. It has a local attack vector, meaning it can only be activated by users with local system access. While this reduces the real-world risk, it does not eliminate it completely.
- The issue is resolved by five upstream patch commits on kernel.org. These introduce a safe fallback that uses
ULLONG_MAXwhen queue count functions return zero. - You can use Nessus Plugin ID 269646 to detect this CVE on your systems. Keep reading to learn how to check your patch status directly from the command line and confirm that you are no longer at risk.
CVE-2021-4460 exploits a vulnerability in the Linux kernel’s AMD GPU driver stack. This vulnerability can be triggered by a single zero return value from a GPU queue function, resulting in undefined behavior.
The vulnerability can be found in the drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c file, which is in charge of managing SDMA (System DMA) queue allocation for AMD GPU hardware. It was discovered on kernel.org and reported to the NVD on 10/01/2025, however, the root of the problem can be traced back to kernel versions beginning with 3.19. This should be considered an active remediation item for security teams monitoring AMD driver exposure and kernel hardening efforts. Tenable’s CVE coverage provides valuable plugin-level detection information for this specific issue.
CVE-2021-4460 Affects AMD GPU Driver Code in Various Kernel Versions
This weakness resides in a very particular part of the Linux kernel — the AMD GPU kernel fusion driver (amdkfd) subsystem. It doesn’t impact all Linux systems, but for settings that run AMD GPUs on kernels that haven’t been patched, it’s a genuine and identifiable code-level defect that UBSAN signals at runtime.
Versions of Linux Kernel Impacted: 5.4.117, 5.10.35, 5.11.19, 5.12.2
The vulnerability impacts several stable kernel branches. Specifically, any kernel running version 5.4 up to and including 5.4.117, 5.10 up to 5.10.35, 5.11 up to 5.11.19, and 5.12 up to 5.12.2 is vulnerable. The vulnerability begins at kernel version 3.19, which is when amdkfd support was first added, making this a long-standing latent issue in the driver’s queue management logic.
The File in Question: drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
The file specifically mentioned in this CVE is drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c. This file is responsible for managing the allocation and initialization of SDMA queues. These Direct Memory Access queues are used by AMD Radeon GPU hardware to transfer data efficiently between system memory and GPU memory.
The queue manager is a crucial part of the amdkfd driver. If it malfunctions because of an undefined bit-shift, the effects can spread through GPU queue scheduling logic. The official Linux stable kernel git at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git is the reference repository for all patch tracking.
SUSE Base Score: 5.8 (CVSS 4.0)
SUSE has given CVE-2021-4460 a base score of 5.8 under CVSS 4.0. This score is considered medium severity. This score is based on the fact that the vulnerability requires local access to exploit — it can’t be exploited remotely over a network — and the potential for it to impact system stability by causing undefined behavior in the kernel.
Just because it’s a medium severity doesn’t mean it’s not a high priority. In hardened kernel environments, any undefined behavior in kernel-space GPU driver code is a reason for patching, especially on systems where local users have access to AMD GPU resources or where kernel integrity is a compliance requirement.
Understanding UBSAN Shift-Out-of-Bounds Error
Before delving into CVE-2021-4460, it’s necessary to comprehend what UBSAN is identifying and why kernel developers are making an effort to rectify it. It’s not a buffer overflow or a use-after-free. Instead, it’s a type of bug that originates in the C language specification and is related to the consequences of exceeding the permissible boundaries of bit-shift operations.
According to the C standard, shifting an integer by a number of bits that is equal to or greater than the width of that integer’s type results in undefined behavior. For example, on a 64-bit system with an unsigned long long type, shifting by 64 bits, which is the full width, is not allowed under the standard. This is despite the fact that some architectures might produce a predictable result.
Understanding Bit-Shift Operations in C
In the C programming language, the left-shift operator (<<) is used to shift bits to the left by a certain number of positions. For instance, 1ULL << 3 would result in the value 8. This operation is commonly used in kernel code for creating bitmasks, assigning queue slots, and manipulating hardware registers. It’s a quick and efficient operation, but only if the shift count remains within the defined limits.
What Happens When You Shift by the Full Bit Width
Shifting a 64-bit value by 64 positions, for example, is considered undefined behavior according to the C standard. This means the compiler can do anything it wants: return zero, return the original value, or generate unpredictable results. In kernel code, this unpredictability can cause silent data corruption or trigger sanitizer warnings that halt execution during debugging.
In the case of CVE-2021-4460, if get_num_sdma_queues() returns 0, the shift count that results from that value will be equal to the bit width of the operand, which directly leads to undefined behavior.
How UBSAN Identifies These Violations in Real Time
UBSAN, also known as the Undefined Behavior Sanitizer, is a tool used during the compilation process that is included in GCC and Clang. This tool adds checks throughout the code that are run in real time. When activated during the kernel build, UBSAN keeps an eye on operations like bit shifts, integer overflows, and null pointer dereferences. If a shift-out-of-bounds takes place during execution, UBSAN issues a warning and has the ability to stop the code path that caused the issue before the undefined behavior can spread further into the system.
The Linux kernel has a CONFIG_UBSAN build option that supports UBSAN. If this is enabled and the amdkfd driver is loaded on an AMD GPU system where the SDMA queue count is zero, you can directly observe CVE-2021-4460 as a UBSAN warning in the kernel log.
- UBSAN is not enabled by default in production kernel builds — it’s primarily used during development and testing
- The underlying undefined behavior still exists even when UBSAN is disabled, it just goes undetected
- Kernel CI pipelines use UBSAN to catch exactly these types of issues before they reach stable releases
- The warning format looks like:
UBSAN: shift-out-of-bounds in kfd_device_queue_manager.cfollowed by the line number and shift values
The Exact Bug in get_num_sdma_queues
Now that the class of vulnerability is clear, here’s exactly what goes wrong inside the amdkfd driver and why a zero queue count is the specific trigger condition for this CVE.
Function of get_num_sdma_queues and get_num_xgmi_sdma_queues
The functions get_num_sdma_queues() and get_num_xgmi_sdma_queues() are both helper functions that are found within the amdkfd queue manager. Their role is to return the number of SDMA queues and XGMI (AMD’s high-bandwidth GPU interconnect) SDMA queues that are available. This is based on the specific AMD GPU hardware that is present within the system. These counts are then used in the creation of bitmasks that keep track of which queue slots are available for allocation.
How the Out-of-Bounds Shift is Triggered by a Zero Return Value
The issue arises when either get_num_sdma_queues() or get_num_xgmi_sdma_queues() returns zero. This occurs on certain AMD GPU configurations where SDMA queues are either not present or not initialized for a specific hardware variant. The queue manager code then takes that zero value and directly uses it in a left-shift operation to construct a bitmask, something like ~0ULL << get_num_sdma_queues(). When the return value is zero, this particular expression is okay. However, the inverse construction, (1ULL << num_queues) - 1, results in a shift-by-zero or shift-by-full-width situation depending on implementation, and that’s when undefined behavior comes into play.
In a more specific sense, if num_sdma_queues is zero and the bitmask construction carries out ~0ULL << num_sdma_queues where the complement logic is reversed, the shift count ends up being the full 64-bit operand width. The C standard does not promise what will happen next. On x86-64 hardware, the processor may quietly return the unshifted value, effectively masking the bug — which is precisely why this type of issue can go unnoticed in production kernels for years without UBSAN enabled.
Why This Is Classified as an Out-of-Bounds Vulnerability
The “out-of-bounds” classification in this case refers specifically to the shift amount going beyond the legal limits defined by the C language standard — not a memory access going beyond the boundary of an array. The shift operand is out of bounds in relation to the bit-width of the type being shifted. UBSAN sees this as a detectable violation, and the CVE classification follows the same logic: the operation goes beyond the defined behavioral limits of the C type system, which in kernel space creates an unpredictable execution state that could be exploited or could contribute to system instability.
Understanding the Kernel Patch Solution
The solution provided by the upstream is straightforward and minimal, which is exactly the type of targeted patch that should be implemented for a low-level kernel driver problem. Instead of changing the logic of the queue manager or adding complicated conditional branches, the patch adds a safe default value that stops the zero-value shift scenario from happening.
The main modification is made directly in kfd_device_queue_manager.c. Before the bitmask is built using num_sdma_queues or num_xgmi_sdma_queues, the patch checks if the returned queue count is zero and replaces it with a safe value. This removes the undefined behavior at its origin without altering the visible behavior for systems where AMD SDMA queues are correctly initialized and return a count that is not zero. For further security insights, you might be interested in reading about the CISA mandates for federal systems.
Using ULLONG_MAX as a Safe Fallback for num_sdma_queues
When get_num_sdma_queues() returns zero, the patched code sets num_sdma_queues to ULLONG_MAX — the maximum value of an unsigned long long, which is 0xFFFFFFFFFFFFFFFF or 18,446,744,073,709,551,615 in decimal. By using ULLONG_MAX as the fallback, a bitmask of all ones is produced through the shift operation, effectively marking all queue slots as unavailable when no valid queue count exists. This is the correct behavior: if there are no SDMA queues, no slots should be allocated, and a full bitmask of ones achieves this result safely and without undefined behavior.
Five Patch Commitments to kernel.org
- Commitment to 5.4 stable branch —
kfd_device_queue_manager.cis fixed withULLONG_MAXfallback. This applies to kernels from version 5.4 up to 5.4.117. - Commitment to 5.10 stable branch — The same logical fix is backported to the 5.10.y series, resolving exposure up to 5.10.35.
- Commitment to 5.11 stable branch — The patch is applied to the 5.11.y series, covering affected versions up to 5.11.19.
- Commitment to 5.12 stable branch — This resolves the issue in the 5.12.y series up to version 5.12.2.
- Mainline upstream commitment — This is the root fix committed to the mainline Linux kernel tree. All stable branch backports originate from here. It is tracked via git commit hash
0c0356ef...in the kernel.org stable repository.
All five commitments target the same single file: drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c. This consistency across branches makes verification straightforward. If your running kernel includes the patched version of this file, you are no longer exposed to CVE-2021-4460.
If you want to check if the patch has been included by commit, you can use git log --oneline drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c in a local clone of the kernel stable tree. Look for the commit hash starting with 0c0356ef in the history of your branch. If it’s there, that means the fix has been implemented.
Kernel packages from distributions that follow the upstream stable kernel, such as SUSE, Ubuntu, Debian, and Red Hat, have included these patches. The SUSE bug tracking entry for this CVE is Bugzilla entry 1250764. This entry records the internal resolution timeline and package update details for SUSE Linux Enterprise and openSUSE users.
Practical Risk for Systems Running Affected Kernel Versions
Severity scores and CVE classifications only tell part of the story. The key is to understand which systems in your environment are actually at risk, what a hacker or a faulty driver could realistically do with this vulnerability, and how urgently you need to prioritize patching against other remediation work that needs to be done. For more insights on how to prepare, check out this exploit storm preparation guide.
Overview of CVE-2021-4460 Vulnerability
Impacted Component: drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
Initial Kernel Affected: 3.19 (amdkfd introduction)
Latest Stable Versions Affected: 5.4.117, 5.10.35, 5.11.19, 5.12.2
Type of Attack: Local
CVSS 4.0 Base Score: 5.8 (Medium)
Source: kernel.org / NVD Published 10/01/2025
Detection Plugin: Nessus Plugin ID 269646
SUSE Bugzilla: #1250764
The exposure window for this vulnerability is quite large. Since the introduction of amdkfd support in kernel 3.19, systems running AMD GPU workloads on unpatched long-term-support kernels for long periods have been harboring this undefined behavior for years. In most production environments, UBSAN is not enabled, which means the bug has been silently present without any noticeable warning in kernel logs.
Those who are running AMD Radeon Instinct or AMD CDNA GPU accelerators on Linux in data center environments, which is typical in machine learning and HPC workloads, should pay particular attention to this CVE. The amdkfd driver is the main kernel interface for ROCm, which is AMD’s GPU compute platform. This means that the kernel versions affected that are running ROCm workloads are directly in the line of fire.
Effect on Confidentiality, Integrity, and Availability (CVSS 4.0 Breakdown)
According to CVSS 4.0, CVE-2021-4460 has effects across three impact dimensions. The undefined behavior happens in kernel space, meaning any resulting instability impacts the whole system, not just a userspace process. Here’s how the effect breaks down:
| CVSS 4.0 Metric | Score | Description |
|---|---|---|
| Attack Vector | Local | Needs local system access; can’t be exploited remotely |
| Attack Complexity | Low | No special conditions necessary beyond causing the zero queue count |
| Confidentiality Impact | Low | Potential for accidental memory state exposure through undefined behavior |
| Integrity Impact | Low | Bitmask corruption might affect queue slot assignment logic |
| Availability Impact | Low | Kernels with UBSAN enabled may halt the affected code path |
| Base Score | 5.8 | Medium severity according to SUSE CVSS 4.0 evaluation |
The low ratings across CIA impact dimensions indicate the limited scope of the bug. It’s not a remote code execution vulnerability, and it doesn’t directly expose user data. However, undefined behavior in kernel code can lead to unexpected results that don’t fit neatly into CVSS impact categories — especially when compiler optimizations interact with undefined behavior in ways that alter surrounding code logic.
Security teams that use risk-based patching frameworks should be aware that “low impact” in terms of CVSS still represents a condition of undefined behavior in kernel space. In environments where kernel integrity is a strict requirement, such as deployments that comply with FedRAMP, Common Criteria, or PCI-DSS, this CVE requires patching, regardless of its medium score.
Local Attack Vector: Who Can Actually Exploit This
Since CVE-2021-4460 has a local attack vector, exploitation necessitates that an attacker already has a presence on the target system. This can be through a legitimate user account, a compromised service, or as part of a chained exploit sequence. In multi-user Linux environments that run AMD GPU workloads, like university HPC clusters or shared GPU compute nodes, this attack surface is wider than it might seem on a single-user workstation. A local user with access to AMD GPU resources could potentially trigger the zero-queue-count condition through specific hardware interaction patterns, invoking the undefined behavior in kernel space.
Identifying CVE-2021-4460 on Your Systems
Identifying this vulnerability requires two steps: determining your kernel version and confirming your patch status. The good news is that both are quick to check, and automated scanning with Nessus makes it easy to detect across your entire fleet, even if you have a large number of systems.
Before you pick up a scanner, begin with a swift manual inspection. If your environment uses AMD GPUs and any of the four affected kernel branches (5.4.x, 5.10.x, 5.11.x, or 5.12.x), consider those systems as potentially vulnerable until the patch status is confirmed. Systems that run non-AMD GPU hardware or kernels that are newer than the patched thresholds are not affected.
How to Use Nessus Plugin ID 269646 to Detect This Vulnerability
The Nessus vulnerability scanner from Tenable has a dedicated Plugin ID 269646 to detect CVE-2021-4460. This plugin checks the version of the kernel that is currently running against the range of versions known to be affected and provides a status report of the exposure. To use it, make sure that your Nessus instance has the most recent plugins, then run a Linux scan with credentials against your AMD GPU systems. The plugin will determine whether the installed kernel falls within the affected range for any of the four stable branches and will flag systems that have not been patched for remediation.
How to Check Your Kernel Version from the Command Line
The quickest way to manually check is with a single command. Run uname -r on any Linux system to see the kernel version that is currently running. Compare what it says to the affected version thresholds: if your kernel reports 5.4.117 or earlier in the 5.4 series, 5.10.35 or earlier in the 5.10 series, 5.11.19 or earlier in the 5.11 series, or 5.12.2 or earlier in the 5.12 series, and the system is running AMD GPU hardware with the amdkfd module loaded, then you are running a kernel that is affected. You can confirm whether amdkfd is loaded with lsmod | grep amdkfd — if the module appears in the output, then the vulnerable code path is active.
Checking if the Patch Has Been Applied Using Git Commit Hash
For those who build their own kernels or need to check patch status beyond a basic version check, the most accurate method is to confirm the fix commit is in your kernel’s git history. To do this, clone the Linux stable kernel repository from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git and check out the branch that matches your running kernel. Then, run git log --oneline drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c and look for a commit message that references the UBSAN shift-out-of-bounds fix. The upstream fix commit hash starts with 0c0356ef. If it’s in your branch history, the patch has been applied.
If you’re working with distribution kernels and don’t have direct access to the source git history, you can check the kernel package changelog. For SUSE systems, you can run rpm -q --changelog kernel-default | grep CVE-2021-4460. If you’re on a Debian or Ubuntu system, run apt-get changelog linux-image-$(uname -r) | grep CVE-2021-4460. Both commands will show whether the CVE fix is included in the kernel package you currently have installed, so you can get a clear answer without needing the entire kernel source tree.
Fixing the Problem: Your Immediate Steps
The solution for CVE-2021-4460 is simple: upgrade your kernel to a version that has the upstream patch. There are no alternatives, configuration adjustments, or runtime mitigations that fix the root undefined behavior — the correction has to be in the compiled kernel code itself. For systems that use AMD GPUs in production, plan the kernel upgrade for your upcoming maintenance window and give it priority over less urgent tasks, especially if those systems are used by multiple users or are part of an infrastructure governed by compliance.
When it’s not possible to update the kernel immediately, a temporary workaround is to unload the amdkfd kernel module by running sudo modprobe -r amdkfd. This removes the vulnerable code path from the running kernel without the need for a reboot, but it also completely disables AMD GPU compute functionality. This should only be used as a temporary solution while a proper kernel update is being prepared, and it’s not a long-term fix.
Upgrade Paths for Each Affected Kernel Branch
Each affected stable branch has a clear and specific safe version to target for remediation:
- Linux 5.4.x branch — upgrade to 5.4.118 or later; any 5.4 kernel beyond 5.4.117 includes the patch
- Linux 5.10.x branch — upgrade to 5.10.36 or later; the fix was integrated immediately after 5.10.35
- Linux 5.11.x branch — upgrade to 5.11.20 or later; 5.11 reached end-of-life shortly after, so migration to 5.15 LTS is strongly recommended
- Linux 5.12.x branch — upgrade to 5.12.3 or later; 5.12 is also end-of-life, making migration to a current LTS branch (5.15 or 6.1) the better long-term path
- Mainline and 5.13+ — kernels in the 5.13 series and newer incorporate the fix from the mainline commit and are not affected
SUSE-Specific Guidance and Bugzilla Entry 1250764
SUSE tracks CVE-2021-4460 under internal Bugzilla entry #1250764. SUSE Linux Enterprise and openSUSE users should apply the kernel updates delivered through the standard SUSE security update channels. Run zypper patch --category security to apply all pending security patches, or target the kernel specifically with zypper update kernel-default. SUSE’s security team has verified the fix across their supported kernel variants, and the CVE is listed as resolved in their security advisory database with the CVSS 4.0 score of 5.8 applied to all affected SUSE products carrying the vulnerable amdkfd driver code.
Understanding CVE-2021-4460: A Look at the Security History of AMD GPU Drivers
Since its debut in Linux 3.19, the amdkfd driver has been a hotbed of kernel development. This was when the Heterogeneous System Architecture (HSA) support from AMD first appeared in the mainline kernel. As one of the Linux kernel’s more intricate GPU subsystems, the amdkfd driver oversees everything from queue scheduling to memory topology for AMD’s compute GPU lineup. Over the years, it has seen a significant number of bug fixes, addressing both functional issues and improvements in code quality relevant to security.
AMD is not the only company with UBSAN-class vulnerabilities in its GPU drivers. The broader DRM (Direct Rendering Manager) subsystem, which includes Intel, NVIDIA’s nouveau driver, and AMD’s amdgpu and amdkfd drivers, has also resolved several UBSAN warnings as kernel developers have increased the use of sanitizers in CI pipelines. The Linux kernel’s adoption of Google’s kernel fuzzer, syzkaller, and the expansion of UBSAN coverage in continuous integration has accelerated the discovery and resolution of latent undefined behavior issues. These issues would otherwise go undetected in production kernels for a long time, as shown by CVE-2021-4460, which has existed since kernel 3.19.
The remarkable aspect of CVE-2021-4460 from a security history viewpoint is the interval between its introduction and the formal assignment of the CVE. The vulnerable code was included in the kernel with the original amdkfd merge, endured through numerous LTS kernel branches, and was only assigned a CVE identifier in 2021, despite the kernel version range beginning at 3.19. This pattern, of latent undefined behavior in hardware driver code being exposed by sanitizer tooling years after its introduction, is becoming increasingly common as the kernel security community applies modern analysis tools to older code paths. Security teams responsible for maintaining long-term kernel deployments should interpret this as a cue to audit the AMD GPU driver update history on any system that has been running the same kernel major version for over 18 months.
Commonly Asked Questions
These are the questions that are most often asked by security teams when they are dealing with CVE-2021-4460 across their Linux kernel fleet.
What systems does CVE-2021-4460 impact?
The CVE-2021-4460 vulnerability impacts systems running Linux kernels in the 5.4.x series up to and including 5.4.117, 5.10.x up to 5.10.35, 5.11.x up to 5.11.19, or 5.12.x up to 5.12.2, with the amdkfd kernel module loaded. The amdkfd module is automatically loaded when AMD GPU hardware is present and the driver is installed, which means any AMD GPU system running these kernel versions could potentially be affected.
Systems that don’t have AMD GPU hardware, including systems that use Intel integrated graphics, NVIDIA GPUs, or run purely as CPU-only servers, are not affected. The vulnerable code in kfd_device_queue_manager.c is only compiled and active when amdkfd support is included in the kernel build. This is standard in most distribution kernels, but it’s irrelevant if the corresponding AMD hardware isn’t present. For more on vulnerabilities, check out the CISA’s mandate on patching Cisco flaws.
Can CVE-2021-4460 be exploited remotely?
No, it can’t. CVE-2021-4460 is classified as having a local attack vector under CVSS 4.0. This means that it can’t be triggered remotely via a network connection. An attacker would need to already have local access to the system, either via a legitimate user account, a compromised local service, or physical access, to interact with the amdkfd driver in such a way that it triggers the zero-queue-count condition.
Although the risk is significantly reduced compared to kernel vulnerabilities that can be exploited over the network, the local attack surface is broader in shared computing environments like HPC clusters, cloud GPU instances with local user access, or university computing labs running AMD GPU hardware, compared to a dedicated single-user workstation. Therefore, these environments should prioritize patching accordingly.
What does ULLONG_MAX mean and why is it used as a solution?
The term ULLONG_MAX is a constant from the C standard library. It is defined in <limits.h> and signifies the maximum value an unsigned long long integer can have. Specifically, it’s 0xFFFFFFFFFFFFFFFF, or 18,446,744,073,709,551,615 in decimal. In the code of the 64-bit Linux kernel, unsigned long long is a 64-bit type. This means that ULLONG_MAX is a 64-bit value where all bits are set to 1.
In the patch, setting num_sdma_queues to ULLONG_MAX when the function that counts queues returns zero creates a bitmask of all ones through the subsequent shift operation. This makes sense: if there are no SDMA queues, the bitmask should show that all queue slots are not available for allocation. Using ULLONG_MAX as the fallback avoids the undefined shift-by-zero-or-full-width situation completely, replacing it with a legal, well-defined operation that produces the correct logical result for the queue manager’s allocation logic.
How can I tell if my kernel has been patched already?
You can quickly check by using uname -r. If your kernel version is 5.4.118 or later, 5.10.36 or later, 5.11.20 or later, or 5.12.3 or later (in their respective branches), the patch is included. For kernels on version numbers at or below the affected thresholds, run lsmod | grep amdkfd to confirm whether the vulnerable module is loaded, then check your distribution’s security advisory list for the specific kernel package version that includes the CVE-2021-4460 fix.
If you want to verify at the source level, use the git commit check described above: search for the commit hash 0c0356ef in the history of drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c in your kernel’s source tree. Nessus Plugin ID 269646 is a tool that automates this detection for large-scale environments managing numerous Linux systems, and it is the recommended method for enterprise fleet verification.
Will non-AMD GPU systems be impacted by CVE-2021-4460?
Not at all. CVE-2021-4460 is solely linked to the amdkfd driver, which is the kernel fusion driver for AMD GPU that is specifically built for AMD Radeon and AMD Instinct GPU hardware. Systems that do not have AMD GPU hardware will not load the amdkfd module and will not be affected by this CVE, even if the kernel version they are running falls within the range that is affected.
Systems with Intel GPUs utilize the i915 driver, NVIDIA systems running on open-source drivers use nouveau, and ARM Mali GPUs employ their own unique driver stack. None of these systems have the vulnerable code in kfd_device_queue_manager.c. Additionally, virtual machines that do not pass through AMD GPU hardware to the guest OS are unaffected, even if the host system has AMD GPU hardware.
If you’re not sure whether your systems have AMD GPU hardware, you can run lspci | grep -i amd and look for entries that reference Radeon, Vega, CDNA, RDNA, or Instinct GPU models. Another way to check is to see if the amdkfd module is present by running modinfo amdkfd. If the command returns module information, then AMD GPU support is compiled into your kernel. If it returns an error, then amdkfd is not available on that system and CVE-2021-4460 does not apply.
You haven’t provided any content to rewrite. Please provide the content that you want to be rewritten.