CVE-2026-45869

What it actually does

This is a race-condition NULL pointer dereference in the Linux kernel wm97xx power-supply driver. During device probe, the driver requests an IRQ before the power_supply object is allocated and registered. If the interrupt fires in that narrow window, the interrupt path can call wm97xx_bat_update() and then power_supply_changed() using an uninitialized or NULL power_supply handle, causing a kernel crash. The practical impact is local denial of service through kernel oops/panic or system instability; confidentiality and integrity are not directly impacted.

Why it matters to the business

Systems using affected Linux kernels with the wm97xx battery/power-supply driver enabled may be vulnerable to local crashes, which can interrupt workloads, embedded devices, kiosks, appliances, or systems relying on this hardware class. The risk is lower than a remote code execution issue because exploitation requires local access or the ability to trigger the relevant device interrupt, EPSS is low, and it is not listed in CISA KEV; however, availability-sensitive or embedded Linux deployments should still prioritize patching because a kernel-level crash can require reboot or manual recovery.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel where the wm97xx power-supply driver is present and the relevant hardware or emulated device path can generate interrupts. The attacker attempts to influence timing during driver initialization so that an IRQ fires after request_irq() succeeds but before power_supply_register() has initialized the power_supply handle. When the interrupt handler runs, it invokes the battery update path, which calls power_supply_changed() with a NULL or uninitialized pointer. This dereference causes a kernel fault, potentially resulting in an oops, panic, reboot, or hung device depending on kernel panic settings and platform behavior. There is no public indication of mature exploitation or active KEV exploitation based on the supplied data.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the fix changing the wm97xx driver probe order so the power_supply handle is registered before request_irq() is called. No exact fixed versions were provided, so use distribution security advisories, stable kernel changelogs, or vendor kernel errata to identify the corrected package. Where immediate patching is not possible, reduce exposure by disabling or unloading the wm97xx battery/power-supply driver if it is not required, removing unsupported affected hardware paths, restricting local shell access, and applying standard controls that prevent untrusted users from loading, binding, or manipulating kernel device drivers. For embedded products, rebuild with the upstream or vendor backport and validate boot/probe behavior on affected hardware.

How to confirm the fix worked

Confirm the system is running a kernel build that includes the wm97xx probe-order fix. Check vendor advisories and kernel package changelogs for references to the wm97xx power_supply_changed NULL pointer dereference fix. Determine exposure by checking whether the wm97xx driver is configured, built, or loaded, such as by reviewing kernel config for CONFIG_BATTERY_WM97XX or related wm97xx options, checking loaded modules, and inspecting boot logs for wm97xx device registration. After patching, reboot into the fixed kernel and confirm the active kernel version matches the patched package. On representative hardware, validate that driver initialization completes without kernel oops messages and that battery/power-supply reporting still functions. If the driver is not needed, confirm it is disabled or absent from the running kernel image or module set.

Typical attack path

1. Gain local user-level access to a system running an affected Linux kernel with the wm97xx power-supply driver enabled and reachable.
2. Identify whether the affected driver is loaded, built into the kernel, or associated hardware is present.
3. Trigger or race device initialization so an IRQ is delivered before the power_supply handle is registered.
4. Cause the interrupt handler to enter wm97xx_bat_update() and call power_supply_changed() with a NULL power_supply pointer.
5. Induce a kernel oops, panic, reboot, or system hang, resulting in denial of service.

How to detect it

Look for signs of prior exploitation or accidental triggering in kernel logs, persistent journald records, crash dumps, and system reboot history. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, journalctl -k, pstore/ramoops records, kdump/vmcore artifacts, watchdog reset logs, and platform management logs. Search for kernel oops or panic entries referencing NULL pointer dereference, power_supply_changed(), wm97xx_bat_update(), wm97xx battery, IRQ handling, or probe-time failures. Correlate crash timestamps with device initialization, module load/unload activity, boot events, suspend/resume cycles, hardware hotplug, or local user activity. Because this vulnerability produces a crash rather than a durable payload, there may be no file-based IOC; evidence is most likely to appear as kernel fault traces and unexpected reboot or panic records.

• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• power_supply_changed
• wm97xx_bat_update
• wm97xx
• wm97xx_battery
• wm97xx battery
• request_irq
• power_supply_register
• /sys/fs/pstore
• /proc/vmcore
• vmcore
• kdump
• ramoops

What your security team should do

• Inventory Linux systems, embedded devices, and appliances that run kernels with wm97xx power-supply support or related hardware enabled.
• Prioritize patching for availability-sensitive systems, embedded fleets, and devices where local users or untrusted workloads can interact with hardware/device initialization.
• Apply vendor kernel updates or backported fixes; if using custom kernels, merge the upstream fix and rebuild.
• If patching is delayed, disable or remove the wm97xx driver where operationally safe, and restrict local access to trusted administrators only.
• Monitor kernel logs for NULL pointer dereferences, oops, panic, or crashes involving wm97xx_bat_update(), power_supply_changed(), or wm97xx battery/power-supply components.
• For appliance or embedded vendors, include regression testing around boot, suspend/resume, battery reporting, and IRQ handling for wm97xx-supported platforms.
• Because EPSS is low and no KEV listing is present, treat this as a targeted availability hardening issue rather than an internet-scale emergency, unless the affected driver is widely deployed in critical devices.