CVE-2024-58052 is a vulnerability identified in the Linux kernel specifically within the AMDGPU driver component, which handles the Direct Rendering Manager (DRM) for AMD graphics hardware. The flaw exists in the function atomctrl_get_smc_sclk_range_table(), which is responsible for retrieving the SMU (System Management Unit) clock speed range table from the video BIOS (VBIOS) data. The vulnerability arises because this function does not verify the return value of smu_atom_get_data_table() before dereferencing it. If smu_atom_get_data_table() fails to retrieve the SMU_Info table and returns a NULL pointer, atomctrl_get_smc_sclk_range_table() will dereference this NULL pointer, leading to a potential NULL pointer dereference vulnerability. This can cause a kernel crash (denial of service) or potentially other undefined behavior depending on the kernel's error handling. The vulnerability is noted to be specific to Polaris AMD GPU chips, as the affected code path is only executed on these devices. The developers note that in practice, this failure should not occur because the VBIOS data table is always present on Polaris chips; however, the lack of defensive programming means that unexpected conditions or corrupted VBIOS data could trigger the issue. The vulnerability was discovered by the Linux Verification Center using static analysis tools (SVACE). There are no known exploits in the wild at this time, and no CVSS score has been assigned yet. The vulnerability affects specific Linux kernel versions identified by commit hashes, indicating it is a recent discovery and patching is expected to be integrated into upcoming kernel releases.

For European organizations, the primary impact of CVE-2024-58052 is the potential for denial of service on Linux systems running AMD Polaris GPUs with the affected kernel versions. This could disrupt services relying on these systems, particularly in environments using Linux for workstations, servers, or embedded systems with AMD GPUs. While the vulnerability does not appear to allow privilege escalation or remote code execution, a kernel crash can cause system downtime, loss of availability, and potential data loss if unsaved work or in-memory data is lost. Organizations in sectors such as finance, manufacturing, research, and public services that rely on Linux-based infrastructure with AMD GPUs could face operational interruptions. The risk is somewhat mitigated by the fact that exploitation requires the presence of specific hardware (Polaris GPUs) and vulnerable kernel versions, and no known exploits exist yet. However, the vulnerability highlights the importance of robust error handling in kernel drivers to prevent stability issues. Given the widespread use of Linux in European IT infrastructure and the presence of AMD GPUs in many systems, this vulnerability warrants attention to maintain system reliability and availability.

European organizations should take the following specific mitigation steps: 1) Identify Linux systems using AMD Polaris GPUs by querying hardware inventories and GPU details (e.g., using lspci and kernel logs). 2) Verify the Linux kernel versions in use and check for the presence of the vulnerable commit hashes or kernel versions. 3) Apply the latest Linux kernel patches as soon as they become available that address CVE-2024-58052. If immediate patching is not possible, consider temporarily disabling or blacklisting the AMDGPU driver for Polaris GPUs if feasible, or restricting access to affected systems to minimize risk. 4) Implement monitoring for kernel crashes or system instability that could indicate attempts to trigger this vulnerability. 5) Engage with Linux distribution vendors and maintain awareness of security advisories related to AMDGPU and kernel updates. 6) For critical systems, perform testing of updated kernels in a controlled environment before deployment to ensure stability and compatibility. 7) Maintain regular backups and disaster recovery plans to mitigate the impact of potential system crashes. These steps go beyond generic advice by focusing on hardware-specific identification, proactive patch management, and operational monitoring tailored to the nature of this vulnerability.