CVE-2026-99215 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
power: supply: core: prevent unregistering a power supply while a callback runs
Once a power supply is registered, its callbacks can immediately start firing from other contexts, such as external_power_changed() triggered by the TCPM stack. If a power supply is unregistered while the callback is still running, the driver data can already be freed when the callback tries to access it, leading to a use-after-free.
This happens e.g. when the hardware bus carrying the power supply device malfunctions (e.g. I2C is hogged down by another malfunctioning device) immediately after the power supply is registered, and thus the core is still processing the callbacks which were queued up when the driver starts the removal, leading in some cases to a kernel crash, e.g.:
[ 11.645942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000005
[ 11.646751] Mem abort info:
[ 11.647006] ESR = 0x0000000096000004
[ 11.647338] EC = 0x25: DABT (current EL), IL = 32 bits
[ 11.647806] SET = 0, FnV = 0
[ 11.648077] EA = 0, S1PTW = 0
[ 11.648356] FSC = 0x04: level 0 translation fault
[ 11.648785] Data abort info:
[ 11.649041] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 11.649524] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 11.649981] GCS = 0, Overlay = 0, DirtyBit = 0
[ 11.650390] [0000000000000005] user address but active_mm is swapper
[ 11.650955] Internal error: Oops: 0000000096000004 [#1] SMP
[ 11.651460] Modules linked in:
[ 11.651742] CPU: 1 UID: 0 PID: 144 Comm: kworker/1:2 Not tainted 7.2.0-rc6-g62a9297af2cd #1 PREEMPT
[ 11.652553] Hardware name: Flipper One rev. F0B1C2 (DT)
[ 11.653024] Workqueue: events power_supply_changed_work
[ 11.653511] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 11.654135] pc : __power_supply_is_supplied_by+0x18/0x100
[ 11.654624] lr : __power_supply_am_i_supplied+0x40/0xb8
[ 11.655098] sp : ffff80008192bb30
[ 11.655399] x29: ffff80008192bb30 x28: 0000000000000000 x27: 0000000000000000
[ 11.656049] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 11.656695] x23: ffff0000c19f4200 x22: ffffdb2232ba4ea8 x21: ffff80008192bc28
[ 11.657344] x20: ffff0000c1eef000 x19: ffff80008192bc18 x18: 00000000a0886e62
[ 11.657991] x17: 000000040044ffff x16: 04500072b5503510 x15: 0000000000000000
[ 11.658639] x14: 0000000000000000 x13: 0000000000000220 x12: 0000000000000000
[ 11.659286] x11: 0000000000000000 x10: ffff0000c1fdb2b0 x9 : ffffdb2232ba5590
[ 11.659934] x8 : 00000000e5b906e6 x7 : ffff0000c2502778 x6 : ffffdb22339793d0
[ 11.660581] x5 : ffff80008192bc18 x4 : ffff0000c19cbca0 x3 : 0000000000000000
[ 11.661228] x2 : ffff0000c1fdaf40 x1 : ffffffffffffffed x0 : ffff0000c1eef000
[ 11.661878] Call trace:
[ 11.662103] __power_supply_is_supplied_by+0x18/0x100 (P)
[ 11.662596] __power_supply_am_i_supplied+0x40/0xb8
[ 11.663040] psy_for_each_psy_cb+0x20/0x40
[ 11.663416] class_for_each_device+0x110/0x150
[ 11.663825] power_supply_am_i_supplied+0x68/0x100
[ 11.664262] bq257xx_external_power_changed+0x58/0x140
[ 11.664733] __power_supply_changed_work+0x60/0x80
[ 11.665170] psy_for_each_psy_cb+0x20/0x40
[ 11.665545] class_for_each_device+0x110/0x150
[ 11.665953] power_supply_changed_work+0x98/0x1b8
[ 11.666382] process_one_work+0x164/0x4c0
[ 11.666758] worker_thread+0x19c/0x320
[ 11.667104] kthread+0x138/0x150
[ 11.667408] ret_from_fork+0x10/0x20
[ 11.667744] Code: d503233f a9bd7bfd 910003fd a90153f3 (f9400c34)
[ 11.668294] ---[ end trace 0000000000000000 ]---
Add a read-write semaphore between external_power_changed() and power_supply_unregister() to prevent the latter from returning (and thus the driver from freeing its data) while the callback is still running.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel power supply subsystem contains a concurrency vulnerability that arises during the device removal process, specifically when unregistering a registered power supply device. This issue stems from a race condition where the core infrastructure allows callbacks to execute asynchronously even after an unregistration request has been initiated but not yet completed. When a power supply is registered with the kernel, its associated callback functions can be triggered immediately by external events or internal state changes, such as those originating from the Type-C Port Controller Manager stack via the external_power_changed function. The critical flaw lies in the lack of synchronization between these ongoing asynchronous callbacks and the device unregistration routine. If a hardware bus malfunction occurs, for instance an I2C bus being hogged by another faulty device, it can delay or disrupt normal operations while queued callbacks remain pending. Consequently, if the power supply is unregistered during this window, the driver's private data structures may be freed before all active callbacks have finished executing. This leads to a use-after-free condition where subsequent callback invocations attempt to access memory that has already been released, resulting in undefined behavior and potential system instability.
The operational impact of this vulnerability is severe, primarily manifesting as kernel crashes due to null pointer dereferences or general protection faults. As evidenced by the provided crash trace from an ARM64 architecture running a Flipper One device, the failure occurs within the __power_supply_is_supplied_by function while processing work queued in power_supply_changed_work. The system attempts to access driver data that has been deallocated because the unregister process completed and freed resources before the callback finished its execution path. This scenario highlights a classic synchronization error where the lifecycle management of kernel objects does not account for pending asynchronous operations initiated by other subsystems. Such instability can lead to denial of service conditions, requiring a system reboot, and in more complex environments with additional attack surfaces, could potentially be leveraged for privilege escalation or arbitrary code execution if an attacker can control the timing of bus errors or trigger specific hardware states that induce this race condition.
From a vulnerability classification perspective, this issue aligns closely with CWE-416, Use After Free, as it involves accessing memory after it has been freed due to improper synchronization. It also relates to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), specifically regarding the interaction between device removal and callback execution contexts. In terms of the MITRE ATT&CK framework for enterprise security, this type of kernel-level race condition can be associated with techniques involving exploitation of software vulnerabilities during system initialization or teardown phases, potentially falling under T1059 Command and Scripting Interpreter if it leads to code execution, though primarily it represents a stability issue categorized under Defense Evasion or Impact depending on the exploitability. The vulnerability underscores the importance of robust lifecycle management in kernel drivers, ensuring that all asynchronous tasks are properly drained or synchronized before resources are reclaimed.
To mitigate this vulnerability, developers have implemented a synchronization mechanism using a read-write semaphore placed between the external_power_changed callback invocation and the power_supply_unregister function. This semaphore ensures that the unregistration process cannot complete and free driver data until any currently running callbacks have finished their execution. By holding a write lock during unregister and acquiring it in the callback path, the kernel guarantees mutual exclusion for these critical sections of code. This fix prevents the race condition by forcing the unregister routine to wait for all active power supply change notifications to conclude before proceeding with memory deallocation. System administrators should ensure that kernels are updated to include this patch, particularly on devices relying heavily on USB Type-C and complex power management hardware where bus errors or timing anomalies might trigger the affected code paths. Regular kernel updates and monitoring of system logs for similar oops traces can help in identifying systems still running vulnerable versions of the power supply core driver.