CVE-2024-52559

What it actually does

User-supplied u32 cmd size and offset values in msm_ioctl_gem_submit() can wrap during addition before buffer validation, allowing improper memory access in the MSM DRM GEM path.

Why it matters to the business

Systems running vulnerable Linux kernels with Qualcomm graphics may face local privilege escalation or crashes; the low EPSS and lack of KEV listing indicate limited real-world exploitation so far, but widespread kernel use raises exposure in embedded and server fleets.

How an attack unfolds

An attacker with local access prepares a crafted gem submit ioctl containing large size and offset values that wrap when added; the missing size_add() check lets the kernel operate on an invalid buffer, potentially leading to out-of-bounds access or code execution.

How to fix it

Apply the upstream patch that replaces direct addition with size_add() in msm_ioctl_gem_submit(); rebuild and deploy the fixed kernel. For ceph-deploy (PyPI) environments, upgrade to version 1.5.23.

How to confirm the fix worked

Confirm the size_add() call is present in the patched msm_gem.c source; run kernel version checks against the fixed release and execute regression tests for the gem submit ioctl path.

Typical attack path

1. Obtain local shell on target Linux system using MSM DRM driver
2. Craft malicious submit command structure with wrapping u32 values
3. Invoke msm_ioctl_gem_submit() via DRM ioctl
4. Trigger integer wrap to bypass size validation
5. Leverage resulting memory corruption for privilege escalation

How to detect it

Review kernel audit logs and dmesg for abnormal DRM GEM submit calls; look for repeated ioctl failures or memory corruption signals around msm_gem_submit in systems with Qualcomm graphics hardware.

What your security team should do

• Prioritize kernel updates on all systems exposing the MSM DRM driver
• Monitor for new EPSS increases or threat actor mentions of similar kernel IOCTL flaws
• Harden local access controls to reduce attack surface for ioctl abuse
• Test the fix in staging before broad rollout given the 608 days since publication