CVE-2024-44982

What it actually does

Failure to release a prepared framebuffer object when dpu_format_populate_layout returns an error leaves the underlying GEM object's pin_count incremented, producing a kernel warning during subsequent drm_gem_object_release and file closure paths.

Why it matters to the business

Systems using the MSM DPU display driver may experience unexpected kernel warnings and potential graphics subsystem instability during normal DRM client shutdown, increasing operational noise and risk of service disruption on affected Linux distributions.

How an attack unfolds

An attacker with local access triggers the error path inside dpu_format_populate_layout by supplying malformed or resource-constrained DRM framebuffer creation parameters; the missing cleanup then leaks the pin reference, which surfaces as a warning only on process exit or DRM file release.

How to fix it

Update the Linux kernel to a version containing commit 9b8b65211a880af8fe8330a101e1e239a2d4008f or later; rebuild and deploy the fixed kernel image, then reboot affected hosts. Where immediate patching is not possible, restrict unprivileged access to the DRM device nodes.

How to confirm the fix worked

Confirm the running kernel contains the fix by checking git log or kernel version string for 9b8b65211a880af8fe8330a101e1e239a2d4008f; attempt to reproduce the original failure condition and verify that no WARNING is emitted in update_lru_locked during DRM file closure.

Typical attack path

1. Obtain local user privileges on a system with the msm DRM driver loaded
2. Issue a DRM_IOCTL_MODE_ADDFB2 or equivalent ioctl that causes dpu_format_populate_layout to fail after the GEM object has been pinned
3. Close the DRM file descriptor or terminate the process to invoke the unbalanced put_pages path
4. Observe the resulting WARNING in update_lru_locked and potential follow-on instability

How to detect it

Search kernel logs for the exact WARNING string referencing update_lru_locked and msm_gem.c:121 around the time of DRM client process termination; correlate with processes that performed framebuffer ioctls on msm devices.

What your security team should do

• Prioritize kernel upgrade on all systems exposing the msm DRM driver to unprivileged users
• Add the fixed commit hash to internal kernel build and distribution pipelines
• Monitor kernel logs for the specific update_lru_locked WARNING pattern until patches are deployed
• Review and tighten permissions on /dev/dri/card* nodes to limit exposure