CVE-2026-90394 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
power: supply: sc2731_charger: cancel work on remove
The USB notifier and initial charger detection can schedule info->work. The remove path unregisters the notifier, but does not cancel queued or running work before the devm-allocated driver data is released.
Set the platform drvdata used by remove, then cancel the work after unregistering the notifier.
This issue was found by a static analysis tool.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The identified vulnerability resides within the Linux kernel power supply subsystem, specifically in the sc2731_charger driver which manages charging operations for devices utilizing the SC2731 PMIC. This flaw represents a classic race condition and use-after-free scenario arising from improper synchronization between asynchronous workqueues and device removal procedures. The core of the issue lies in the lifecycle management of the driver's internal state, particularly regarding scheduled kernel work items that are initiated during USB notifier registration and initial charger detection phases. When these events occur, they schedule a specific work item to handle charging logic updates or status changes asynchronously relative to the main execution flow.
The critical failure occurs during the device removal process when the platform driver is being unloaded. While the code correctly proceeds to unregister the USB notifier to prevent future callbacks from triggering new tasks, it fails to address any work items that have already been queued in the kernel's workqueue system or are currently executing on a CPU core. Because the driver data structure containing necessary context for this work item is allocated using devm (device-managed memory), its lifetime is tied directly to the device's presence in the system. Once the remove function completes and returns, the framework automatically frees this devm-allocated memory. If the previously scheduled or running work item attempts to access any member of this freed structure during or after the removal process, it will result in a use-after-free condition. This can lead to kernel panics, data corruption, or potentially exploitable arbitrary code execution depending on how the corrupted memory is interpreted by the scheduler and subsequent operations.
From a technical classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources without proper synchronization. The specific mechanism of accessing freed memory places it squarely within CWE-416, Use After Free. In terms of offensive security frameworks such as MITRE ATT&CK for Enterprise or ICS, this type of flaw is often leveraged in privilege escalation attacks where an attacker might trigger the removal and re-insertion of a device rapidly to exploit the race window between memory deallocation and workqueue execution. The fact that this issue was discovered by static analysis tools highlights the importance of automated code auditing for kernel drivers, as these logical errors are frequently invisible during standard functional testing unless specific timing conditions are met.
The operational impact of this vulnerability is significant due to its potential to destabilize the entire operating system. A successful exploitation could cause a denial of service through a kernel oops or panic, requiring a full reboot of the affected device. In more severe scenarios involving memory corruption, it could allow an attacker with local access to escalate privileges by manipulating heap structures via the use-after-free condition. This is particularly dangerous in embedded systems and mobile devices where power management drivers are critical for system stability and security boundaries between user space and kernel space must be strictly maintained.
To mitigate this vulnerability, the driver implementation requires a strict ordering of operations during device removal. The platform drvdata pointer should be explicitly set or validated to ensure safe access before any cleanup actions begin. Crucially, after unregistering the USB notifier to stop new work items from being scheduled, the code must invoke cancel_work_sync or similar synchronization primitives on the info->work item. This ensures that if a work item is currently running, it will complete its execution safely without accessing freed memory, and if it is queued but not yet started, it will be removed from the queue entirely before the driver data structure is released by the devm framework. This sequence guarantees that no asynchronous tasks retain references to deallocated resources, thereby eliminating the race condition and preventing use-after-free exploits.