CVE-2023-54047

What it actually does

Use-after-free in the embedded DRM encoder within rockchip_hdmi during component unbind, where container memory is freed before the main DRM device is destroyed, causing a crash on module removal (rmmod).

Why it matters to the business

Kernel instability or crashes on systems with Rockchip HDMI hardware during driver unload operations, leading to potential denial of service in environments that dynamically manage kernel modules.

How an attack unfolds

An attacker with local access loads the affected dw_hdmi driver, then triggers rmmod to force unbind; the encoder reference is accessed after its container is freed, resulting in a use-after-free crash. No widespread remote exploitation or named threat actors are associated with this issue.

How to fix it

Update the Linux kernel to include commit 110d4202522373d629d14597af9bac97eb58bd67. For karpenter-1.0 (Chainguard) upgrade to version 1.0.10-r1. Rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the encoder cleanup call occurs before clk_disable in the unbind path by inspecting the drm/rockchip/dw_hdmi source; perform rmmod testing to verify absence of use-after-free crashes or oops.

Typical attack path

1. Gain local shell or module management access on an affected Linux system
2. Ensure the rockchip dw_hdmi DRM component is bound
3. Execute rmmod on the module to initiate unbind and container teardown
4. Trigger the use-after-free via the stale encoder reference leading to kernel crash

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for oops or panic messages referencing drm/rockchip or dw_hdmi during module unload events; correlate with rmmod audit logs.

What your security team should do

• Prioritize kernel updates on Rockchip-based systems within standard patching cycles given low EPSS and lack of KEV status
• Restrict unprivileged module loading via kernel parameters where feasible
• Include DRM-related oops patterns in kernel log monitoring