CVE-2026-46270

What it actually does

This is a Linux kernel use-after-free race in the rt9455 power-supply driver. The driver requests its interrupt handler before allocating/registering the power_supply object using device-managed resources, so teardown occurs in the opposite order: the power_supply object can be freed before the IRQ handler is unregistered. If an interrupt fires during device removal, module unload, driver unbind, or a related probe/remove race window, the IRQ handler can call power_supply_changed() with a freed or uninitialized pointer. The likely result is a kernel crash, but memory corruption may also be possible and could theoretically be shaped into local privilege escalation on systems with the affected hardware and driver enabled.

Why it matters to the business

Affected Linux systems using the rt9455 power-supply/charger driver may be vulnerable to local denial of service through kernel panic and, in higher-risk scenarios, kernel memory corruption with potential full system compromise. The issue is not known to be exploited in the wild, is not in CISA KEV, has very low EPSS, and requires local access plus the relevant driver/hardware path, so exposure is most important for Linux-based appliances, embedded devices, mobile/IoT platforms, and systems where the rt9455 charger driver is present.

How an attack unfolds

An attacker first needs local execution capability or another way to influence the affected device lifecycle and interrupt behavior. On a system with the rt9455 driver active, the attacker attempts to create the vulnerable timing condition by causing driver probe/removal activity, such as device unbind/rebind, module unload, power-management transitions, or teardown of the charger device, while also causing or waiting for an rt9455 interrupt. If the interrupt is handled after the power_supply object has been freed, the kernel IRQ handler dereferences stale memory in power_supply_changed(). In the simplest case this crashes the kernel and causes a denial of service. A more advanced attacker may try to groom kernel memory so the freed object is replaced with controlled data, potentially turning the race into kernel memory corruption or privilege escalation. No public exploit maturity is reported for this CVE.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, or upstream stable kernel branch that includes the rt9455 driver fix ordering IRQ registration after power_supply registration. No exact fixed package versions were provided in the input, so use vendor advisories and kernel changelogs for CVE-2026-46270 or the rt9455 power-supply driver patch. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the rt9455 driver if the hardware is not required, preventing untrusted users from loading/unloading kernel modules or rebinding devices, restricting physical access to affected embedded/mobile hardware, and avoiding unnecessary driver unbind/rebind or hotplug operations until patched.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package contains the rt9455 fix, not merely that an updated package is installed on disk; reboot into the patched kernel if required. Check vendor advisories, kernel changelogs, or source code to ensure the rt9455 driver registers the power_supply object before requesting the IRQ. Validate exposure by checking whether the rt9455 driver is built into the kernel or loaded as a module, whether matching hardware is present, and whether logs show rt9455 initialization. On test systems, safe validation should focus on code/package verification rather than trying to reproduce the race, because reproduction can crash the host and may corrupt memory.

Typical attack path

1. Identify a Linux system that includes and loads the rt9455 power-supply driver.
2. Obtain local execution or physical/peripheral-level influence sufficient to affect charger/driver state or trigger relevant interrupts.
3. Cause driver lifecycle activity such as module unload, device unbind/rebind, probe failure, device removal, or suspend/resume transitions.
4. Trigger or race an rt9455 interrupt during the narrow window after the power_supply handle is freed or before it is fully initialized.
5. Force the IRQ handler to call power_supply_changed() with a freed or invalid power_supply pointer.
6. Achieve a kernel crash, or attempt heap grooming to convert the use-after-free into controlled kernel memory corruption.

How to detect it

Look for evidence of exploitation or attempted triggering in kernel and system logs rather than network telemetry, because this is a local kernel driver race. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, KASAN/KMSAN/KFENCE reports, audit logs for module load/unload or sysfs driver bind/unbind activity, and EDR telemetry for commands interacting with /sys/bus/*/drivers, modprobe, rmmod, insmod, or power-management interfaces. Suspicious patterns include kernel oops or panic events involving rt9455, power_supply_changed(), IRQ handling, use-after-free, slab corruption, or crashes immediately after device unbind/rebind, module removal, suspend/resume, or charger-related interrupts. There are no known public attacker-specific IOCs or threat actors for this CVE; detection should focus on behavioral artifacts and kernel fault signatures.

• rt9455
• power_supply_changed
• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• use-after-free in power_supply_changed
• general protection fault
• kernel NULL pointer dereference
• kernel BUG at
• Unable to handle kernel paging request
• Oops:
• Kernel panic - not syncing
• slab-use-after-free
• rmmod rt9455
• modprobe -r rt9455
• /sys/bus/i2c/drivers/rt9455/unbind
• /sys/bus/i2c/drivers/rt9455/bind

What your security team should do

• Prioritize patching Linux-based embedded, mobile, appliance, or IoT systems that use the rt9455 charger/power-supply driver.
• Inventory systems for the rt9455 driver using kernel configuration, module listings, boot logs, and hardware manifests.
• If the driver is not needed, disable or blacklist it until a patched kernel is deployed.
• Restrict local administrative paths that allow module unload, device unbind/rebind, debugfs/sysfs driver manipulation, or forced power-device resets.
• Monitor kernel logs for crashes, KASAN reports, use-after-free messages, and rt9455 or power_supply_changed-related faults.
• Because EPSS is low, exploit maturity is reported as none, and the CVE is not KEV-listed, treat this as targeted-priority rather than internet-wide emergency patching unless affected hardware is broadly deployed in critical devices.