CVE-2026-98781 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Fix pdev reference leak in mtk_drm_bind()
When the device is not the mmsys master, mtk_drm_bind() returns early after taking a reference on the disp-mutex device via of_find_device_by_node(), without ever dropping it: mtk_drm_unbind() only puts mutex_dev for the master. Drop the reference before returning from the non-master path.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel's DRM Mediatek driver involves a resource management error within the mtk_drm_bind function, specifically concerning device node references acquired through the of_find_device_by_node API. This issue arises during the initialization phase when the system attempts to bind display subsystem components. The core technical flaw is an imbalance in reference counting for hardware mutex devices. When the current device being probed is not designated as the master mmsys component, the driver correctly identifies and acquires a reference to the disp-mutex device via of_find_device_by_node to ensure proper synchronization resources are available. However, upon determining that it is not the master, the function executes an early return path without releasing this acquired reference. This oversight means that while the kernel retains a hold on the mutex device object, no corresponding cleanup operation is scheduled for this specific instance during subsequent driver unbinding or removal processes.
The operational impact of this memory and resource leak manifests as a gradual depletion of system resources over time, particularly in systems where display drivers are frequently loaded and unloaded or when multiple instances of similar hardware configurations exist. Although the immediate effect might appear negligible due to the small size of device structures, repeated occurrences can lead to reference count leaks that prevent the underlying mutex devices from being properly released back to the kernel pool. This not only consumes memory but also potentially blocks other drivers or subsystems from accessing these critical synchronization primitives if their lifecycle management becomes entangled with unreleased references. In severe cases, such resource exhaustion could contribute to system instability or failure to initialize new display components after prolonged uptime or repeated driver reloads.
From a vulnerability classification perspective, this defect aligns closely with CWE-401, which describes the missing release of memory after successful allocation, and more specifically relates to improper reference counting mechanisms often categorized under resource management errors. In terms of attack surface and exploitation potential, while this is primarily an internal kernel logic error rather than a direct remote code execution vector, it falls under categories related to Denial of Service through resource exhaustion if triggered repeatedly by local users with appropriate privileges to load or manipulate driver modules. The ATT&CK framework would classify this type of issue within the broader context of persistence or impact tactics where system resources are degraded over time, although its primary classification remains a stability and reliability defect rather than an active security exploit vector for external attackers.
Mitigation strategies focus on correcting the code logic to ensure symmetry in reference counting operations. The definitive fix involves modifying the mtk_drm_bind function to explicitly drop the reference obtained via of_find_device_by_node before returning from the non-master conditional branch. This ensures that every acquisition of a device node reference is matched with a corresponding release, maintaining kernel integrity and preventing leaks. For system administrators and developers, applying the latest stable Linux kernel patches that include this specific DRM Mediatek fix is essential to resolve the issue. Additionally, rigorous code review processes emphasizing resource lifecycle management in driver development can prevent similar defects from being introduced into other parts of the kernel or third-party modules.