CVE-2022-50378 in Linux
Résumé
par VulDB • 01/07/2026
Based on the KASAN (Kernel Address Sanitizer) trace provided, here is an analysis of the bug:
### **Summary** This is a **Use-After-Free (UAF)** or potentially a **Double-Free** error in the Meson DRM driver subsystem. The kernel detected that memory was freed by `task 2695` during module removal (`meson_dw_hdmi_remove`), but this free operation occurred while another task (`task 0`) still held a reference to it (or attempted to access it).
### **Key Details from the Trace** 1. **Allocator Task**: `Allocated by task 0` - The memory was originally allocated when the system or driver was initialized/running under context of task 0. 2. **Freeing Task**: `Freed by task 2695` - The free happened during module unload: ``` meson_dw_hdmi_remove -> component_del -> take_down_aggregate_device -> meson_drv_unbind -> component_unbind_all -> devres_release_group -> release_nodes -> kfree ``` 3. **Buggy Address**: `ffff000020c39000` - This address belongs to a slab object that was freed during the cleanup path of the `meson_dw_hdmi` driver.
### **Root Cause Analysis** The issue lies in the interaction between: - The **Meson DRM master driver** (`meson_drm`) - The **HDMI encoder sub-driver** (`meson_dw_hdmi`)
During module removal (`delete_module`), `component_del()` is called, which triggers unbinding of all components. This leads to `devres_release_group()`, which frees resources allocated via devm (device-managed) APIs or explicit allocations tied to the device lifetime.
However, **task 0** still has a reference to this memory. Possible scenarios: 1. **Race Condition**: A worker thread, interrupt handler, or delayed work associated with task 0 is accessing the HDMI encoder state after it has been freed during unbind. 2. **Missing Cleanup in Task 0 Path**: The code path running on task 0 did not properly synchronize with or stop before `component_unbind_all()` was called. For example: - A CRTC/encoder update function might be executing concurrently with the remove callback. - An atomic commit or page flip operation may have been in-flight when removal started.
### **Likely Bug Location** Look at code paths that access `meson_dw_hdmi` private data structures from: - Atomic driver callbacks (`atomic_begin`, `atomic_commit_tail`) - Encoder helper functions (e.g., `encoder_enable`, `encoder_disable`) - Any workqueue or interrupt context associated with the HDMI encoder
Specifically, check if there is any **asynchronous operation** that accesses freed memory after `meson_dw_hdmi_remove()` has been called.
### **Recommended Fix Strategy** 1. **Ensure Synchronization**: Make sure all asynchronous operations (workqueues, IRQs) are flushed or stopped before calling `component_del()`. 2. **Check Reference Counting**: Ensure no dangling pointers remain in task 0’s context after unbind. 3. **Use Devm Properly**: If resources were allocated with devm APIs (`devm_kzalloc`, etc.), they should be automatically freed when the device is removed, avoiding manual `kfree` races. However, if mixed with non-devm allocations or custom cleanup logic, ensure ordering is correct. 4. **Add Debugging Prints**: Insert printks in both allocation and free paths to confirm timing relative to task 0’s access.
### **Example Code Pattern That Might Cause This** ```c // In meson_dw_hdmi.c static void my_encoder_enable(struct drm_encoder *encoder) {
struct meson_drm_private *priv = ...; // May point to freed memory if remove happened priv->hdmi_state = ACTIVE; // UAF! }
static int meson_dw_hdmi_remove(...) {
component_del(...); // Triggers unbind and free of resources return 0; } ```
### **Conclusion** This is a concurrency bug in the Meson DRM HDMI driver where memory freed during module removal is still accessed by another task. Fix requires ensuring proper synchronization between async operations and the remove/unbind path.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.