CVE-2021-47471

What it actually does

NULL pointer dereference occurs in the mxsfb DRM driver when mxsfb_unload calls drm_irq_uninstall which invokes mxsfb_irq_disable while crtc.funcs has already been cleared, though mxsfb->base remains valid.

Why it matters to the business

Driver unload on affected systems can trigger a kernel crash leading to unplanned reboots or service disruption during maintenance or module removal.

How an attack unfolds

An attacker with local access unloads the mxsfb driver module or triggers the unload path, causing the kernel to dereference a NULL function pointer and panic.

How to fix it

Update the Linux kernel to a version containing the fix that masks the IRQ directly via mxsfb->base instead of calling through the NULL funcs pointer; apply the patch or newer stable release that resolves the mxsfb unload sequence.

How to confirm the fix worked

Confirm the kernel source contains the updated mxsfb_unload path that performs direct IRQ masking from mxsfb->base; test module load/unload cycles on mxsfb hardware without observing a crash.

Typical attack path

1. Obtain local code execution or shell on the target system
2. Unload or trigger removal of the mxsfb DRM kernel module
3. Kernel executes mxsfb_unload which calls drm_irq_uninstall on a partially torn-down crtc
4. NULL dereference in mxsfb_irq_disable results in panic or crash

How to detect it

Review kernel logs for oops or panic traces containing mxsfb_unload, drm_irq_uninstall, or mxsfb_irq_disable around the time of driver removal or module unload events.

What your security team should do

• Prioritize kernel updates on systems using the mxsfb DRM driver
• Audit init scripts and module management to avoid unnecessary driver unload on production hosts
• Monitor for kernel oops or panic events referencing mxsfb during maintenance windows