CVE-2023-53864

What it actually does

NULL pointer dereference in drm/mxsfb driver when overlay plane framebuffer is NULL during atomic update, causing kernel oops.

Why it matters to the business

Local denial of service via kernel crash on systems using the mxsfb display driver; low exploitability reduces immediate risk but still requires patching to maintain stability.

How an attack unfolds

An attacker with local access triggers the mxsfb_plane_overlay_atomic_update path on an overlay plane, passing a NULL framebuffer pointer that leads to dereference and crash when the disable logic is incorrectly placed.

How to fix it

Update to Linux kernel containing commit 8bf2d4ca521d3acb57fc1607386e749b3cc92aaf or later; apply the equivalent fix that moves overlay disable logic into mxsfb_plane_overlay_atomic_disable().

How to confirm the fix worked

Confirm kernel version includes the referenced commit; test overlay plane atomic disable sequences do not trigger NULL pointer dereference; monitor for absence of oops in dmesg after driver updates.

Typical attack path

1. Obtain local shell or user context on affected Linux system
2. Interact with DRM subsystem to manipulate overlay plane state via atomic operations
3. Trigger atomic_update followed by disable sequence causing NULL dereference
4. Kernel oops occurs resulting in system instability or reboot

How to detect it

Search kernel logs for oops messages referencing mxsfb_plane_overlay_atomic_update or NULL pointer dereference in drm/mxsfb; examine recent DRM atomic operations preceding crashes.

What your security team should do

• Prioritize kernel updates on systems using mxsfb driver within standard patch cycles
• Review and apply the atomic disable function change from the fix commit
• Monitor EPSS and exploit maturity for any increase indicating new public code