CVE-2024-50156

What it actually does

NULL pointer dereference in msm_disp_state_print_regs() when msm_disp_state_dump_regs() allocation fails, allowing kernel crash via unhandled NULL block->state despite attempted guard code.

Why it matters to the business

Low-likelihood system instability or denial of service on Linux kernels with MSM display hardware; no ransomware or known exploitation campaigns increase urgency.

How an attack unfolds

Attacker triggers display state dump path under memory pressure causing allocation failure, then relies on the flawed NULL check to dereference a NULL dump_addr pointer; listed threat actors and Linux kernel campaigns do not align with this specific flaw.

How to fix it

Apply the upstream patch that prints "Registers not stored" on NULL and refactors the function to use a const single pointer; update affected Linux kernel packages to versions containing the fix.

How to confirm the fix worked

Confirm kernel source contains the updated msm_disp_state_print_regs() logic that explicitly checks for NULL state and avoids double-pointer usage; test by forcing dump allocation failure and verifying graceful message instead of crash.

Typical attack path

1. Trigger allocation failure in msm_disp_state_dump_regs()
2. Invoke msm_disp_state_print_regs() on the resulting state object
3. Execute the flawed if (*reg) guard that initializes dump_addr to NULL
4. Dereference dump_addr causing kernel fault

How to detect it

Search kernel logs and crash dumps for NULL dereference signatures in drm/msm code paths; review dmesg or journalctl for msm_disp_state_print_regs calls under low-memory conditions; no specific threat actor IOCs apply.

What your security team should do

• Prioritize kernel updates on systems with MSM/DRM display drivers
• Monitor for any downstream dependents using affected kernel versions
• Review logging around display state dumps for unexpected NULL handling