CVE-2026-93194

What it actually does

Failure to call unbind cleanup in dw_dp_bind error paths and component unbind leaves DisplayPort AUX channel and other core resources registered, resulting in use-after-free when device teardown or dependent device operations later access the freed structures.

Why it matters to the business

Systems using Rockchip DRM DisplayPort hardware may experience kernel crashes, memory corruption, or local privilege escalation during driver load/unload or hotplug events, increasing downtime and potential compromise on affected Linux devices.

How an attack unfolds

An attacker with local access triggers repeated module load/unload or device probe sequences that exercise the bind error path or component unbind without proper resource release, allowing subsequent kernel operations to dereference freed memory for denial of service or code execution.

How to fix it

Update to a Linux kernel containing the referenced commit that invokes dw_dp_unbind in the component unbind callback and bind error path; rebuild and deploy the updated kernel image on all affected Rockchip DRM systems.

How to confirm the fix worked

Confirm the presence of dw_dp_unbind calls inside dw_dp_rockchip_unbind and the bind error handler in the rockchipdrm driver source; test module insert/remove cycles under KASAN or similar memory debuggers to verify absence of use-after-free reports.

Typical attack path

1. Obtain local shell or userland execution on target system
2. Trigger rockchipdrm or dw_dp module probe or unbind via hardware events or explicit driver reload
3. Force bind failure or component teardown that skips dw_dp_unbind
4. Perform follow-on kernel operations that touch the stale AUX channel pointers
5. Achieve slab use-after-free for crash or exploitation

How to detect it

Review kernel logs for KASAN reports citing slab-use-after-free in device_is_dependent during modprobe or rockchip_drm_platform_probe; inspect dmesg for call traces referencing dw_dp_bind and device_link_add on systems with Radxa ROCK 5B or equivalent DT hardware.

What your security team should do

• Prioritize kernel updates on all Rockchip-based devices within standard patch windows given low EPSS and no KEV listing
• Restrict local module loading and driver attach privileges where feasible
• Monitor kernel logs for KASAN or slab-use-after-free reports involving device_is_dependent or dw_dp_bind
• Include the fix in next maintenance kernel build and test on representative ROCK 5B or similar hardware