CVE-2026-98782

What it actually does

The flaw is a platform device leak in the Mediatek DRM probe and remove paths: mtk_drm_probe registers an OVL adaptor device via platform_device_register_data but fails to unregister it on subsequent initialization errors or on normal driver unbind, leaving the device registered indefinitely.

Why it matters to the business

Repeated driver load/unload cycles or probe failures on affected hardware can exhaust kernel resources, potentially causing display subsystem instability, increased memory usage, or denial of service on systems using the Mediatek display pipeline.

How an attack unfolds

An attacker with the ability to trigger repeated DRM driver probe attempts or module load/unload sequences (for example via crafted hardware configuration or local module manipulation) can cause the OVL adaptor device to be allocated without being freed, gradually depleting platform device slots and associated memory until the system becomes unresponsive.

How to fix it

Update to a Linux kernel containing the referenced fix that tracks OVL adaptor registration state and properly unregisters the device on both probe error paths and normal removal.

How to confirm the fix worked

Confirm the presence of the fix by inspecting the mtk_drm_probe and removal functions for registration-state tracking and explicit platform_device_unregister calls; test by inducing probe failures and verifying that no orphaned OVL adaptor platform devices remain after error recovery.

Typical attack path

1. Gain local access or ability to influence DRM device initialization on target hardware
2. Trigger mtk_drm_probe under conditions where a later initialization step fails
3. Repeat the failing probe or module reload cycle to accumulate leaked platform devices
4. Observe resource exhaustion or driver instability

How to detect it

Examine kernel logs for repeated mtk_drm_probe failures followed by increasing numbers of registered platform devices; look for platform device registration events without corresponding unregistration in dmesg or driver debug output.

What your security team should do

• Prioritize kernel updates on systems using Mediatek DRM hardware within normal patch cycles given low exploitability
• Monitor upstream stable kernel releases for the backported fix
• Limit unprivileged module loading where feasible to reduce attack surface for repeated probe attempts