CVE-2026-74422 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()
Driver makes use of drmm_encoder_init() to initialize the encoder and automatically handle the cleanup by registering drm_encoder_cleanup() with drmm_add_action().
However, the internal structure containing the encoder part gets allocated with devm_kzalloc(), which happens while component_bind_all() is being called from Rockchip DRM driver. The component framework further ensures it is deallocated as part of releasing all the resources claimed during bind, which is triggered from component_unbind_all().
When the reference to the DRM device gets eventually dropped via drm_dev_put() in rockchip_drm_unbind(), drmm_encoder_alloc_release() attempts to access the now released encoder structure, leading to use-after-free.
Ensure driver's internal structure is still reachable on encoder cleanup by switching from a device-managed allocation to a drm-managed one.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's rockchip display subsystem where the inno-hdmi driver implementation contains a critical use-after-free condition that can lead to system instability and potential privilege escalation. The flaw manifests during the DRM device cleanup process when the driver attempts to manage encoder resources through improper memory allocation patterns that create timing conflicts between different resource management frameworks.
The technical root cause stems from the improper mixing of device-managed allocation mechanisms with DRM-managed resource handling. The driver uses drmm_encoder_init() which internally registers cleanup actions via drmm_add_action() to automatically handle encoder resource deallocation. However, the underlying encoder structure itself is allocated using devm_kzalloc() during component_bind_all() execution within the Rockchip DRM framework. This creates a race condition where the device-managed allocation gets freed during component_unbind_all() while the DRM-managed cleanup mechanism still attempts to access the same memory region through drmm_encoder_alloc_release().
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable privilege escalation attacks as demonstrated by the CWE-416 use-after-free condition. When drm_dev_put() triggers rockchip_drm_unbind(), the cleanup sequence becomes malformed because the memory allocation lifecycle is managed by two competing frameworks without proper coordination. This situation creates a window where memory that has been freed by the device manager remains referenced by the DRM cleanup handler, leading to undefined behavior and system instability.
This vulnerability directly relates to ATT&CK technique T1068 which involves exploiting local privilege escalation opportunities through kernel vulnerabilities. The improper resource management pattern violates fundamental principles of memory safety in kernel space operations where multiple resource managers must coordinate their lifecycle events carefully. The fix requires switching from device-managed allocation patterns (devm_kzalloc) to DRM-managed allocation (drmm_kzalloc) to ensure consistent lifecycle management throughout the driver's operational phases.
The vulnerability demonstrates how modern Linux kernel drivers must maintain strict adherence to their respective resource management frameworks, particularly when dealing with complex subsystem integrations like DRM components. The improper use of component framework integration combined with DRM-specific cleanup mechanisms creates a scenario where memory deallocation timing conflicts can be exploited by malicious actors. This represents a classic case of resource lifecycle management failure that can be addressed through proper allocation pattern selection and adherence to the established kernel driver development practices for each subsystem's resource management requirements.
The fix implementation requires careful examination of the driver's memory allocation strategy to ensure all internal structures maintain their validity throughout the complete device lifecycle, from initialization through final cleanup. This involves switching from devm_kzalloc() to drmm_kzalloc() for the encoder structure allocation to align with the DRM-managed resource cleanup approach that is already established by the drmm_encoder_init() function call. Such a change ensures consistent memory management across all driver operational phases and eliminates the timing window where the use-after-free condition could occur during the unbind process.