CVE-2026-45916

What it actually does

This is a Linux kernel use-after-free race in the SBS battery power-supply driver. The vulnerable driver requests its interrupt handler before the power_supply object is fully registered, and managed cleanup later releases the power_supply object before the IRQ handler is unregistered. During device probe or removal, an interrupt can arrive at the wrong time and cause the IRQ handler to call power_supply_changed() with either an uninitialized or already freed power_supply pointer. The likely result is a kernel crash, but because the bug is a use-after-free in kernel memory, it can also create memory corruption with potential local privilege escalation depending on kernel configuration, timing control, and available exploitation primitives.

Why it matters to the business

Systems using affected Linux kernels with SBS battery hardware or exposed battery-management interfaces may be vulnerable to local denial of service and potentially full system compromise by a user who can trigger or influence the vulnerable device/driver path. The practical operational risk is highest for laptops, embedded systems, industrial devices, appliances, and battery-backed platforms that load the sbs-battery driver. There is no indication that this is being exploited in the wild, it is not in CISA KEV, and EPSS is very low, but the CVSS impact is high because successful exploitation occurs in kernel context and can affect confidentiality, integrity, and availability.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel with the vulnerable SBS battery driver active or loadable. The attacker then attempts to create timing conditions around device probe, removal, suspend/resume, hotplug, module unloading, driver unbinding, or battery/ACPI/SMBus events so that the battery interrupt fires while the power_supply object is not yet initialized or has already been freed. If the race is won, the IRQ handler calls power_supply_changed() on an invalid object. In the simplest case, the kernel dereferences freed or invalid memory and crashes, causing a denial of service. A more advanced attacker may attempt to shape heap state and interrupt timing so that the stale pointer references attacker-influenced kernel memory, potentially enabling kernel memory corruption and privilege escalation. Exploitation is expected to be timing-sensitive and hardware/driver-dependent, and no public mature exploit is currently indicated.

How to fix it

Upgrade to a vendor kernel that includes the sbs-battery driver fix which requests the IRQ only after the power_supply handle is registered, ensuring cleanup ordering cannot leave the IRQ handler referencing freed memory. Because no exact fixed versions were provided, use the latest stable kernel or distribution security update from the relevant OS, appliance, or device vendor and verify that the patch for drivers/power/supply/sbs-battery has been backported. If immediate patching is not possible, reduce exposure by disabling or blacklisting the sbs-battery driver where it is not required, preventing untrusted users from loading/unloading kernel modules or binding/unbinding devices, restricting physical or management access to battery/SMBus interfaces, and limiting local shell access to trusted administrators. Mitigations are not equivalent to patching because the issue is in kernel driver lifecycle ordering.

How to confirm the fix worked

Confirm the system is running a patched vendor kernel or a kernel build containing the corrected sbs-battery initialization order. Review vendor advisories, kernel changelogs, or source/backport patches for the fix in drivers/power/supply/sbs-battery. On Linux systems, verify the running kernel with uname -r and compare it to the vendor-fixed release. Check whether the vulnerable driver is loaded with lsmod, modinfo, or sysfs module paths, and confirm whether SBS battery hardware is present under /sys/class/power_supply or related ACPI/SMBus device trees. For mitigation validation, verify that the sbs-battery module cannot be loaded where it is not needed, module loading is restricted, and unprivileged users cannot perform driver bind/unbind or power-device management operations. If testing in a lab, exercise battery-related suspend/resume, hotplug, driver probe, and removal paths while monitoring dmesg for KASAN, use-after-free, general protection fault, or kernel oops messages.

Typical attack path

1. Obtain local authenticated access to a Linux system running an affected kernel.
2. Confirm that the SBS battery driver is present, loaded, or can be triggered through supported hardware or firmware interfaces.
3. Trigger repeated battery, SMBus, ACPI, power-supply, hotplug, suspend/resume, driver bind/unbind, or module lifecycle events to exercise probe or removal paths.
4. Race an interrupt against power_supply registration or cleanup so that the IRQ handler runs with an invalid power_supply pointer.
5. Cause kernel memory corruption or a kernel panic through power_supply_changed() operating on freed or uninitialized memory.
6. Use the crash for denial of service, or, if a reliable memory-corruption primitive is developed, attempt local privilege escalation in kernel context.

How to detect it

To determine whether this was already exploited, review kernel logs, persistent journal entries, crash dumps, pstore/ramoops records, and EDR telemetry for signs of kernel memory corruption or panics involving the SBS battery driver or the power-supply subsystem. Useful log sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, kdump/vmcore analysis, pstore entries under /sys/fs/pstore, and crash reporting systems such as ABRT, apport, or vendor appliance diagnostics. Look for KASAN or slab reports showing use-after-free near power_supply_changed(), stack traces involving sbs_battery or drivers/power/supply/sbs-battery.c, and crashes occurring during suspend/resume, battery events, driver unbind, device removal, or module unload. Also review audit or shell history where available for suspicious local activity involving modprobe, rmmod, insmod, sysfs driver bind/unbind files, or repeated power-management actions immediately preceding a crash. There are no known network indicators for this issue because exploitation is local and driver/hardware-dependent.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in power_supply_changed
• power_supply_changed
• sbs-battery
• sbs_battery
• drivers/power/supply/sbs-battery.c
• BUG: unable to handle kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel BUG at drivers/power/supply
• Oops:
• Kernel panic - not syncing
• /sys/bus/i2c/drivers/sbs-battery
• /sys/bus/i2c/drivers/sbs-battery/bind
• /sys/bus/i2c/drivers/sbs-battery/unbind
• /sys/class/power_supply
• /sys/fs/pstore
• rmmod sbs_battery
• modprobe sbs_battery

What your security team should do

• Inventory Linux systems, appliances, laptops, embedded platforms, and battery-backed devices that may load the sbs-battery driver.
• Prioritize patching systems where local users are present, untrusted workloads run, kernel module loading is permitted, or physical/management access to battery-related interfaces exists.
• Apply the latest vendor-supported kernel updates and verify that the sbs-battery power_supply/IRQ ordering fix is included or backported.
• Where the driver is unnecessary, blacklist or disable sbs-battery and validate that it is not loaded after reboot.
• Restrict local administrative capabilities that can trigger driver bind/unbind, module unload/load, suspend/resume automation, or low-level device access.
• Enable and monitor kernel crash, oops, and panic telemetry across Linux fleets, especially for power_supply_changed(), sbs-battery, and KASAN use-after-free messages.
• Treat unexplained crashes involving the power-supply subsystem as potential security events until patched status and root cause are confirmed.