CVE-2026-89900 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
media: cec: core: Fix kmemleak due to missed rc_free_device() call
The commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device.
kmemleak reports following after e.g. dw-hdmi unbind:
unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598
Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel media subsystem contains a memory management flaw within the Consumer Electronics Control (CEC) core code that results in a persistent memory leak, specifically identified as a kmemleak issue. This vulnerability stems from an incomplete refactoring of device lifecycle management functions during previous maintenance efforts aimed at resolving race conditions between device unregistration and interrupt or USB request block callbacks. The original intent was to decouple the freeing of remote control devices from their unregistration process to prevent use-after-free scenarios, but the implementation introduced a logical error in reference counting and cleanup sequencing that leaves allocated memory unreleased under specific driver detach conditions.
The technical root cause lies in the interaction between rc_unregister_device() and cec_delete_adapter(). A prior commit removed the implicit call to rc_free_device() from rc_unregister_device() to address concurrency issues, but it failed to remove a subsequent NULL assignment of the adap->rc pointer. This assignment effectively nullifies the reference to the allocated remote control device structure before the cleanup phase is complete. Consequently, when cec_delete_adapter() attempts to free resources after the last user of the CEC device exits, it encounters a NULL pointer instead of a valid memory address, causing rc_free_device() to be skipped entirely. This results in the kernel retaining ownership of the allocated memory block without any active references pointing to it, creating an unreferenced object that persists until system reboot or module reload.
From an operational perspective, this vulnerability manifests as a gradual degradation of system resources over time, particularly on systems where CEC-capable hardware such as HDMI controllers is frequently probed and unbound during development, testing, or dynamic driver loading scenarios. The kmemleak tool detects these unreferenced objects by tracking memory allocations that are never freed through normal deallocation paths. In the reported case involving the dw-hdmi driver, each instance of device binding followed by unbinding leaks a 4096-byte kernel slab object. While individual instances may seem negligible, repeated occurrences can lead to significant memory pressure in long-running systems or embedded devices with limited RAM, potentially contributing to out-of-memory conditions if left unchecked over extended periods.
This issue is classified under CWE-401, which describes a missing release of memory after effective usage, and aligns with ATT&CK technique T1539 regarding potential data exfiltration through resource exhaustion in some contexts, though primarily it represents a denial-of-service vector via resource depletion rather than direct information disclosure. The flaw highlights the complexity of managing shared kernel resources where multiple abstraction layers interact, emphasizing the need for rigorous code review when modifying lifecycle management functions to ensure that all allocation sites have corresponding and correctly sequenced deallocation paths.
The resolution involves removing the erroneous NULL assignment of adap->rc within the relevant cleanup routine. By preserving the pointer value until after cec_delete_adapter() has executed its full teardown sequence, the kernel ensures that rc_free_device() is invoked with a valid memory address, allowing proper release of the allocated slab object back to the system allocator. This fix restores the correct reference counting behavior and eliminates the leak without reintroducing the race conditions that motivated the original changes.
To mitigate similar issues in other parts of the kernel or third-party drivers, developers should adhere strictly to established patterns for device lifecycle management, ensuring that allocation functions are always paired with their corresponding free functions regardless of intermediate state changes. Utilizing static analysis tools like kmemleak during development and continuous integration testing can help detect such leaks early before they reach production environments. Additionally, code reviews focusing on pointer assignments immediately preceding cleanup routines should verify that no nullification occurs prior to the actual deallocation step, maintaining data integrity throughout the object's lifetime.