CVE-2024-26938

What it actually does

Null pointer dereference in intel_bios_encoder_supports_dp_dual_mode() when devdata is NULL due to missing VBT or undeclared encoder, resulting in kernel oops.

Why it matters to the business

Local denial of service via system crashes on Linux systems using i915 graphics; low urgency given 896 days since publication, stable 0.0022 EPSS, and no ransomware or KEV usage despite mentions of Android kernel threats.

How an attack unfolds

An attacker with local access on an affected system without VBT data invokes the function through normal graphics initialization paths, triggering the NULL dereference and kernel panic; unrelated references to Android kernel RCE actors do not align with this local-only flaw.

How to fix it

Update to fixed kernel commits such as a891add409e3bc381f4f68c2ce9d953f1865cb1f or equivalent stable releases; apply the NULL check patch from commit 26410896206342c8a80d2b027923e9ee7d33b733.

How to confirm the fix worked

Verify presence of the early bail for devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() in kernel source or confirm updated package versions across affected distributions.

Typical attack path

1. Gain local user access on target Linux system
2. Trigger graphics or display initialization involving i915 BIOS encoder checks
3. Cause NULL devdata condition leading to kernel oops and crash

How to detect it

Search kernel logs and oops reports for references to intel_bios_encoder_supports_dp_dual_mode or devdata handling during boot or display setup; correlate with local user activity around crash times.

• intel_bios_encoder_supports_dp_dual_mode
• devdata==NULL

What your security team should do

• Prioritize kernel updates on all i915-based systems within standard patch cycles
• Monitor for kernel oops reports in logs as a detection signal
• Review graphics driver initialization in high-availability environments