CVE-2024-38664: Linux Kernel Privilege Escalation Flaw

CVE-2024-38664 Overview

A race condition vulnerability has been discovered in the Linux kernel's zynqmp_dpsub driver within the Direct Rendering Manager (DRM) subsystem. The vulnerability stems from improper mutex initialization timing in the DRM bridge registration process, where zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which expects hpd_mutex to be initialized before use. This creates a dangerous situation where the mutex lock operation occurs on an uninitialized lock structure.

Critical Impact

Local attackers with low privileges can potentially exploit this race condition to cause system instability, kernel lockdep warnings, and potentially achieve privilege escalation or denial of service on affected Xilinx Zynq UltraScale+ MPSoC systems running vulnerable Linux kernel versions.

Affected Products

• Linux Kernel versions prior to the security fix (commit 61ba791c4a7a)
• Linux Kernel 6.10-rc1 (specifically affected)
• Systems using Xilinx Zynq UltraScale+ MPSoC with DisplayPort subsystem

Discovery Timeline

• 2024-06-24 - CVE CVE-2024-38664 published to NVD
• 2025-05-30 - Last updated in NVD database

Technical Details for CVE-2024-38664

Vulnerability Analysis

This vulnerability is classified under CWE-667 (Improper Locking), representing a race condition that occurs during kernel subsystem initialization. The issue manifests in the DRM bridge registration flow of the zynqmp_dpsub driver, which handles display output on Xilinx Zynq UltraScale+ MPSoC platforms.

The core problem lies in the sequence of operations during driver initialization. The zynqmp_dp_hpd_work_func function, which handles hot-plug detection events, calls drm_bridge_hpd_notify. This notification function requires the hpd_mutex to be properly initialized before any lock acquisition attempt. However, the original code flow did not ensure bridge registration (and consequently mutex initialization) occurred before the HPD work function could be scheduled and executed.

When the mutex is accessed before proper initialization, the kernel's lockdep debugging infrastructure detects this invalid state and generates a DEBUG_LOCKS_WARN_ON(lock->magic != lock) warning at kernel/locking/mutex.c:582. This indicates that the lock structure's magic number does not match the expected value, confirming the lock was never initialized properly.

Root Cause

The root cause is an incorrect initialization order in the zynqmp_dpsub driver. The DRM bridge must be registered (which initializes the hpd_mutex) before zynqmp_dpsub_drm_init is called, as that function invokes drm_bridge_attach. Without this ordering guarantee, there exists a window where the HPD work queue event (zynqmp_dp_hpd_work_func) can execute and attempt to acquire the uninitialized mutex.

The fix ensures the DRM bridge is always registered before any code paths that might call drm_bridge_hpd_notify, guaranteeing the mutex is properly initialized when the lock acquisition occurs.

Attack Vector

This vulnerability requires local access to the system with low privileges. An attacker would need to trigger a hot-plug detection event on the DisplayPort subsystem during the vulnerable window of the driver initialization phase. While the attack complexity is local in nature, successful exploitation could lead to:

• Kernel panic or system crash due to corrupted lock state
• Potential privilege escalation if the race condition can be reliably triggered
• Denial of service through repeated triggering of the vulnerability
• Memory corruption in kernel space affecting system integrity and confidentiality

The workqueue subsystem (events workqueue running zynqmp_dp_hpd_work_func) processes these hot-plug events asynchronously, which creates the timing window necessary for exploitation.

Detection Methods for CVE-2024-38664

Indicators of Compromise

• Kernel log messages containing DEBUG_LOCKS_WARN_ON(lock->magic != lock) warnings
• Stack traces showing __mutex_lock failures originating from drm_bridge_hpd_notify
• Workqueue errors referencing zynqmp_dp_hpd_work_func in the call trace
• Lockdep warnings specifically at kernel/locking/mutex.c:582

Detection Strategies

• Monitor kernel logs (dmesg or /var/log/kern.log) for mutex lock warnings related to DRM subsystem
• Implement kernel log analysis rules to detect DEBUG_LOCKS_WARN_ON patterns with drm_bridge references
• Enable CONFIG_DEBUG_MUTEXES and CONFIG_LOCKDEP in kernel configuration for enhanced detection
• Use SentinelOne's kernel-level telemetry to identify abnormal mutex operations in display drivers

Monitoring Recommendations

• Configure centralized logging to aggregate kernel messages from all affected Xilinx Zynq UltraScale+ systems
• Set up alerts for workqueue failures involving the zynqmp_dpsub or zynqmp_dp driver components
• Monitor for unexpected display subsystem resets or hotplug events during system initialization
• Deploy endpoint detection solutions capable of analyzing kernel-level events and race conditions

How to Mitigate CVE-2024-38664

Immediate Actions Required

• Update to a patched Linux kernel version containing the security fix
• If immediate patching is not possible, avoid triggering DisplayPort hot-plug events during system boot
• Review kernel configuration to ensure CONFIG_DRM_ZYNQMP_DPSUB is disabled if DisplayPort functionality is not required
• Monitor affected systems for signs of exploitation until patches can be applied

Patch Information

The vulnerability has been resolved through patches committed to the Linux kernel stable branches. The fix ensures the DRM bridge is always registered before zynqmp_dpsub_drm_init is called, properly initializing the hpd_mutex before any potential use.

Official patches are available from the following kernel git commits:

• Kernel Git Commit 6036613
• Kernel Git Commit 6ead3ec
• Kernel Git Commit be3f304

The fix was cherry-picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae.

Workarounds

• Disable the zynqmp_dpsub driver by adding drm_zynqmp_dpsub.disable=1 to kernel boot parameters if DisplayPort is not required
• Blacklist the zynqmp_dpsub module by adding blacklist zynqmp_dpsub to /etc/modprobe.d/blacklist.conf
• Ensure DisplayPort cables are not connected during boot sequence to avoid triggering HPD events during the vulnerable initialization window
• Consider using alternative display output methods if available on the hardware platform

# Disable zynqmp_dpsub module loading (temporary workaround)
echo "blacklist zynqmp_dpsub" >> /etc/modprobe.d/blacklist-zynqmp.conf
update-initramfs -u

# Verify the module is not loaded
lsmod | grep zynqmp_dpsub

# To apply kernel update on Debian/Ubuntu-based systems
apt update && apt upgrade linux-image-$(uname -r)

# To apply kernel update on RHEL/CentOS-based systems
yum update kernel