CVE-2024-43901 is a vulnerability identified in the Linux kernel specifically within the AMD GPU Direct Rendering Manager (DRM) driver subsystem, targeting the display component (drm/amd/display). The flaw arises from a NULL pointer dereference triggered when users attempt to read the DTN (Display Technology Node) log via the debug filesystem path /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log. The root cause is that the color log functionality tries to access gamut remap information from the DCN401 ASIC (a specific AMD display engine version) which is not properly initialized in the dcn401_dpp_funcs structure. This leads to a NULL pointer dereference because the gamut_remap callback function pointer is missing or unimplemented for this ASIC variant. When the kernel attempts to execute this callback, it dereferences a NULL pointer, causing a kernel oops and system crash. The kernel logs show a page fault in kernel mode with a call trace pointing to the amdgpu driver functions responsible for logging hardware state and color state. The issue is addressed by adding a guard condition to check if the gamut_remap callback is implemented before invoking it, preventing the NULL pointer dereference. This vulnerability is triggered by a local user running a read command on a debug file, which is typically accessible only to privileged users or those with debugfs access. There are no known exploits in the wild at this time, and no CVSS score has been assigned yet. The vulnerability affects Linux kernel versions containing the specified commit hashes prior to the patch. The flaw impacts system stability by causing kernel crashes, potentially leading to denial of service (DoS) conditions. It does not appear to allow privilege escalation or code execution directly but can disrupt availability of the system or GPU functionality.

For European organizations, the primary impact of CVE-2024-43901 is on system availability and stability, particularly for those using Linux systems with AMD GPUs that include the DCN401 display engine. This includes servers, workstations, and embedded systems running vulnerable Linux kernel versions. Organizations relying on AMD GPU hardware for graphics-intensive workloads, visualization, or compute tasks may experience unexpected kernel panics and system reboots if the vulnerability is triggered. While exploitation requires local access and the ability to read debugfs files, insider threats or compromised user accounts could leverage this to cause denial of service. This could disrupt critical operations in sectors such as finance, manufacturing, research, and public services that use Linux-based infrastructure with AMD GPUs. Additionally, the vulnerability could affect cloud providers or data centers hosting Linux virtual machines with passthrough AMD GPUs, impacting service availability. Since the flaw is in a kernel driver, it may also affect containerized environments or virtualized workloads using AMD GPU acceleration. The lack of remote exploitability limits the threat scope, but the impact on availability and potential operational disruption is significant for affected systems.

1. Apply the official Linux kernel patch that adds the guard to prevent NULL pointer dereference in the amdgpu driver as soon as it is available and integrated into your distribution's kernel updates. 2. Restrict access to debugfs, especially the /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log file, to trusted and privileged users only, minimizing the risk of local exploitation. 3. Monitor kernel logs for signs of NULL pointer dereference or kernel oops related to amdgpu and drm subsystems to detect attempted exploitation or instability. 4. For critical systems, consider disabling debugfs or mounting it with restricted permissions if debug functionality is not required. 5. In environments using AMD GPUs with DCN401 ASICs, validate kernel versions and hardware compatibility to ensure patched versions are deployed. 6. Employ system integrity monitoring and endpoint detection tools to identify anomalous local user behavior that could trigger this vulnerability. 7. Coordinate with Linux distribution vendors and AMD for timely updates and advisories related to this vulnerability. 8. For cloud or virtualized environments, ensure hypervisor and guest kernel versions are updated to mitigate this issue in GPU passthrough scenarios.