CVE-2021-47063

What it actually does

Failure to manually invoke drm_connector_cleanup in panel_bridge_detach leaves a devm-allocated drm_connector that is later accessed after its memory has been released during drm_mode_config_cleanup, producing a use-after-free.

Why it matters to the business

Kernel crashes or potential local privilege escalation on Linux systems that use DRM panel bridges can interrupt graphics workloads and require emergency patching across fleets.

How an attack unfolds

An attacker with local access loads or unloads a DRM driver that attaches and detaches a panel bridge, timing the operations so the stale connector pointer is dereferenced after the underlying memory has been freed.

How to fix it

Update to a Linux kernel containing the fix that ensures drm_connector_cleanup is called in panel_bridge_detach when the connector was created.

How to confirm the fix worked

Confirm the presence of the cleanup call inside panel_bridge_detach and verify that no use-after-free warnings appear in kernel logs during bridge attach/detach cycles.

Typical attack path

1. Obtain local unprivileged access on a Linux system using affected DRM panel bridges.
2. Trigger repeated attach/detach cycles of a panel bridge via driver load/unload or hotplug events.
3. Force the devm-managed connector to be released while DRM still holds references to it.
4. Trigger subsequent drm_mode_config_cleanup to dereference the freed object and achieve code execution or denial of service.

How to detect it

Review kernel logs for use-after-free or slab corruption messages referencing drm_connector or panel_bridge; inspect call traces around drm_mode_config_cleanup and panel_bridge_detach.

What your security team should do

• Prioritize kernel updates on all systems exposing DRM graphics drivers.
• Monitor for kernel oops or slab-use-after-free reports involving drm_connector objects.
• Restrict unprivileged module loading until patches are applied.