CVE-2026-90298 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/sun4i: tcon: Drop TCON TOP device reference
of_find_device_by_node() takes a device reference. Drop it after mux configuration succeeds.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The identified issue resides within the Display Controller (TCON) driver for Allwinner sun4i architectures in the Linux kernel, specifically affecting the management of hardware resources during display initialization and reconfiguration processes. The vulnerability stems from an improper handling of device references obtained through the Device Tree API function of_find_device_by_node(). This function is designed to retrieve a pointer to a struct device associated with a specific node in the system's device tree hierarchy while simultaneously incrementing the reference count on that device object. This mechanism ensures that the target device remains valid and its resources are not prematurely released by other subsystems or drivers during active usage. However, failure to balance this acquisition with a corresponding release operation leads to a resource leak, specifically a memory leak associated with the kref structure embedded within the device object.
In practical operational terms, when the TCON TOP driver invokes of_find_device_by_node() to locate and configure the multiplexer for display timing control, it acquires a reference that is never released if the configuration succeeds or even in certain error paths depending on the specific code flow. While this may appear as a minor oversight in isolated instances, repeated execution during system boot sequences, hot-plug events of displays, or dynamic resolution changes can accumulate these unreleased references over time. This accumulation results in a gradual increase in kernel memory consumption that is not reclaimed until the entire device object is destroyed, which typically only occurs when the driver module is unloaded or the system shuts down. In long-running embedded systems where such drivers are frequently utilized for display management, this leak can contribute to overall system instability and eventual out-of-memory conditions if left unaddressed.
From a security perspective, while resource leaks in kernel space are primarily classified as reliability issues rather than direct exploitation vectors like buffer overflows or privilege escalation flaws, they fall under the category of CWE-401: Missing Release of Memory after Effective Lifetime. This weakness allows an attacker with local access to potentially exhaust system resources through repeated triggering of the affected code path, leading to a Denial of Service condition against other processes sharing the same memory pool. Furthermore, in environments where kernel stability is critical for security boundaries, such as container runtimes or virtualization hosts relying on specific display subsystems for hardware acceleration, resource exhaustion can indirectly compromise availability guarantees. The ATT&CK framework categorizes this type of behavior under Resource Hijacking, specifically within techniques that involve consuming system resources to degrade service quality or cause crashes without necessarily gaining unauthorized access to data.
The resolution involves ensuring proper reference counting hygiene by calling the appropriate release function, typically put_device(), after the successful completion of the multiplexer configuration task. This ensures that the reference count is decremented correctly, allowing the kernel memory management subsystem to reclaim the allocated structures when no other references remain. To mitigate similar issues in broader contexts, developers should adhere strictly to the principle of balanced resource acquisition and release within device drivers. Implementing static analysis tools configured to detect unbalanced refcount operations can help identify such defects early in the development lifecycle. Additionally, code reviews focusing on Device Tree API usage patterns are essential for maintaining kernel stability, particularly in complex subsystems like DRM where multiple devices interact dynamically during runtime configuration changes.