CVE-2026-53308 in Linux
Summary
by MITRE • 06/26/2026
In the Linux kernel, the following vulnerability has been resolved:
power: supply: max77705: Free allocated workqueue and fix removal order
Use devm interface for allocating workqueue to fix two bugs at the same time:
1. Driver leaks the memory on remove(), because the workqueue is not destroyed.
2. Driver allocates workqueue and then registers interrupt handlers with devm interface. This means that probe error paths will not use a reversed order, but first destroy the workqueue and then, via devm release handlers, free the interrupt.
The interrupt handler schedules work on this exact workqueue, thus if interrupt is hit in this short time window - after destroying workqueue, but before devm() frees the interrupt - the schedulled work will lead to use of freed memory.
Change is not equivalent in the workqueue itself: use non-legacy API which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is used to update power supply (power_supply_changed()) status, thus there is no point to run it for memory reclaim. Note that dev_name() is not directly used in second argument to prevent possible unlikely parsing any "%" character in device name as format.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/26/2026
The vulnerability in the Linux kernel's max77705 power supply driver represents a critical memory management issue that could lead to system instability and potential security implications. This flaw manifests in two interconnected problems that arise from improper resource handling during driver initialization and removal sequences. The root cause stems from the driver's use of mixed allocation interfaces where workqueues are allocated without proper device-managed (devm) handling, while interrupt handlers utilize the devm interface for cleanup operations.
The primary memory leak occurs during driver removal when the workqueue allocated during probe phase is not properly destroyed, leading to persistent memory allocation that cannot be reclaimed by the system. This represents a classic resource management failure that violates fundamental kernel security principles and can contribute to system exhaustion over time. The secondary issue involves a race condition between interrupt handler execution and cleanup operations that creates an exploitable window where scheduled work items may attempt to access freed memory structures.
This vulnerability directly relates to CWE-401: "Improper Release of Memory Before Removing Last Reference" and CWE-362: "Concurrent Execution using Shared Resource with Improper Synchronization." The improper ordering of resource cleanup operations creates a temporal window where interrupt handlers can schedule work items on workqueues that have already been destroyed, resulting in use-after-free conditions. Such conditions can be leveraged by malicious actors to execute arbitrary code or cause system crashes through controlled memory corruption.
The operational impact extends beyond simple memory leaks to include potential system instability and denial of service scenarios. When interrupt handlers execute during the cleanup window, they may trigger work items that reference freed memory locations, potentially causing kernel oops, system panics, or more subtle corruption patterns that could be exploited for privilege escalation. The timing aspect of this vulnerability makes it particularly dangerous as it can occur during normal system operation when power supply status changes are being monitored.
The proposed fix addresses these issues by implementing proper device-managed workqueue allocation using the devm interface consistently throughout the driver lifecycle. This ensures that cleanup operations follow the correct reverse order, with workqueues being destroyed before interrupt handlers are freed, eliminating the race condition window. Additionally, the change moves away from legacy workqueue APIs that include memory reclaim flags which are inappropriate for power supply status update operations that should not interfere with system memory management during critical reclaim scenarios.
The implementation follows ATT&CK framework concept T1068: "Exploitation for Privilege Escalation" by addressing underlying kernel memory corruption vulnerabilities that could be exploited to gain elevated privileges. The solution aligns with security best practices by ensuring proper resource lifecycle management and eliminating potential attack vectors through improved synchronization mechanisms. The modification also addresses the specific concern about dev_name() usage in format string contexts, preventing potential parsing issues that could introduce additional security risks through improper input handling.
This fix demonstrates the importance of consistent resource management patterns in kernel drivers and highlights how seemingly minor interface inconsistencies can create significant security implications. The change ensures proper memory lifecycle management while maintaining the functional requirements of power supply status updates, providing a robust solution that prevents both memory leaks and use-after-free conditions through careful attention to resource allocation order and cleanup semantics.