CVE-2026-45936

What it actually does

This is a Linux kernel use-after-free race in the Goldfish power supply driver. The driver can request an interrupt before the power_supply object is fully registered, and device-managed cleanup frees/unregisters objects in reverse order. During probe or removal, an interrupt may fire while the power_supply handle is uninitialized or already freed, causing the interrupt handler to call power_supply_changed() on invalid memory. In practical terms this can trigger a kernel crash, memory corruption, and potentially local privilege escalation if an attacker can reliably influence the race and heap layout. The CVSS vector indicates local access with low attack complexity and low privileges, with potential impact to confidentiality, integrity, and availability.

Why it matters to the business

Systems using affected Linux kernels with the Goldfish power supply driver exposed may be vulnerable to local denial of service and, in a worst case, local privilege escalation. This is most relevant to Android emulator, virtualized, test, CI, or development environments that include Goldfish platform devices; typical physical server and desktop deployments are less likely to expose this driver. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS at this time, so broad internet-scale exploitation is unlikely; however, kernel privilege escalation issues should still be prioritized on multi-user systems, shared build infrastructure, and environments running untrusted workloads.

How an attack unfolds

An attacker first needs local code execution or the ability to run a workload on a system using an affected kernel and the Goldfish power supply driver. They then attempt to trigger driver probe or removal paths while causing or racing a relevant interrupt so that the interrupt handler executes before the power_supply object is initialized or after it has been freed. If the race is won, the handler calls power_supply_changed() with an invalid pointer. The most likely observable result is a kernel oops, panic, or system crash. A more advanced attacker may attempt repeated races with heap grooming to turn the memory corruption into controlled kernel memory access and potentially elevate privileges.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Goldfish power supply driver, which requests the IRQ only after the power_supply handle has been allocated and registered. If a vendor distribution is used, apply the vendor-provided kernel update rather than relying only on upstream version numbers. No fixed package versions were provided in the input, so security teams should consult their Linux distribution, Android/emulator platform, appliance, or cloud image vendor advisories for the exact patched kernel release. If immediate patching is not possible, reduce exposure by disabling or removing the Goldfish power supply driver where it is not required, preventing untrusted users from loading/unloading kernel modules or managing virtual devices, and isolating untrusted workloads from affected emulator or CI hosts.

How to confirm the fix worked

Confirm the running kernel package includes the Goldfish power supply driver fix from the relevant vendor or upstream stable branch. Validate by checking vendor advisory status, kernel changelog entries, or source patches for the Goldfish power supply driver showing IRQ request ordering after power_supply registration. On systems where the driver is not required, confirm it is not loaded and not built into the active kernel. Operationally, review dmesg or journal logs after reboot and driver lifecycle testing for absence of kernel oops, KASAN use-after-free reports, or crashes involving power_supply_changed() and Goldfish power supply code.

Typical attack path

1. Obtain local, low-privileged code execution on a Linux system where the Goldfish power supply driver is present and active.
2. Confirm that the affected driver/device path is available, typically in an emulator or virtualized Goldfish environment.
3. Trigger driver initialization or teardown paths, such as device probe, removal, suspend/resume-like behavior, or module/device lifecycle events where applicable.
4. Race a Goldfish power supply interrupt against object registration or cleanup.
5. Cause the interrupt handler to call power_supply_changed() using an uninitialized or freed power_supply handle.
6. Achieve a kernel crash or attempt further heap manipulation to convert the use-after-free into privilege escalation.

How to detect it

Look for evidence of kernel crashes or memory-safety reports around the Goldfish power supply driver. Relevant log sources include dmesg, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, hypervisor or emulator logs, and CI runner logs for emulator hosts. Search for kernel oops, panic, BUG, KASAN, slab use-after-free, general protection fault, or page fault messages that include power_supply_changed, Goldfish power supply code, IRQ handling, or driver probe/removal timing. If exploitation is suspected, correlate repeated local crashes with user activity, module/device lifecycle events, emulator start/stop events, or attempts to trigger hardware interrupts. Absence of these artifacts does not prove non-exploitation, because a successful privilege escalation may not crash the system and may leave few driver-specific indicators.

• power_supply_changed
• goldfish
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• unable to handle kernel NULL pointer dereference
• slab-use-after-free
• power: supply: goldfish
• goldfish battery
• goldfish_battery
• Call Trace:
• IRQ

What your security team should do

• Inventory Linux systems, emulator hosts, Android development infrastructure, CI runners, and virtualized test platforms that may use Goldfish devices or kernels with the Goldfish power supply driver.
• Prioritize patching shared, multi-user, CI/CD, emulator, sandbox, and untrusted-workload environments before isolated single-user development systems.
• Apply vendor kernel updates that include the driver fix; reboot systems to ensure the patched kernel is running.
• Where the driver is unnecessary, disable the Goldfish power supply driver or use a kernel configuration/image that excludes it.
• Restrict local administrative interfaces that can trigger device add/remove, module lifecycle, or emulator hardware changes to trusted users only.
• Monitor kernel logs for oops, panic, KASAN, or use-after-free messages involving power_supply_changed or Goldfish power supply components.
• Because there is no current KEV listing, no known ransomware usage, and low EPSS, treat this as a targeted/local kernel-risk issue rather than an internet-facing emergency unless affected systems run untrusted local code.