CVE-2026-46246

What it actually does

This is a Linux kernel use-after-free in the pm8916_lbc power-supply driver. The driver registers a device-managed IRQ before registering the extcon handle, so during device removal the extcon object can be freed before the IRQ handler is unregistered. If an interrupt fires in that narrow window, the IRQ handler can call extcon_set_state_sync() with a freed pointer, causing a kernel crash or potential memory corruption. Because the vulnerable code runs in kernel context, successful exploitation can affect confidentiality, integrity, and availability of the host, but exploitation requires local access and a system using the affected driver/hardware path.

Why it matters to the business

Systems that include and use the affected Linux kernel driver may be exposed to local denial of service or possible local privilege escalation. The most likely operational impact is an unexpected kernel crash or instability during device removal, driver unbind, module unload, reboot, suspend/resume, or power-management activity. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS at this time, but the high CVSS impact means exposed embedded, mobile, appliance, or ARM-based Linux deployments should still receive normal kernel security updates.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system where the pm8916_lbc driver is present and bound to matching hardware. The attacker then attempts to cause the affected driver to be removed, unbound, or otherwise torn down while also causing or racing a charger/battery-related interrupt. In the vulnerable ordering, the extcon handle may be released before the interrupt handler is fully unregistered. If the interrupt arrives during that race window, the handler dereferences the freed extcon pointer through extcon_set_state_sync(). The common result is a kernel oops, panic, or device reboot. In a more advanced scenario, a local attacker may attempt to shape heap reuse around the freed object to turn the memory corruption into kernel-code execution or privilege escalation, though no public exploit maturity is currently reported.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the pm8916_lbc driver, which changes the allocation/registration ordering so the IRQ is requested after the extcon handle is registered and is therefore released before the extcon object during teardown. No exact fixed package versions were provided, so use the latest security kernel from the relevant Linux distribution, device vendor, SoC vendor, or appliance vendor. Where immediate patching is not possible, reduce exposure by disabling or avoiding use of the affected driver on systems that do not require it, restricting local shell access, restricting write access to driver bind/unbind sysfs interfaces, preventing unprivileged module loading/unloading, and limiting administrative interfaces that can trigger device removal or power-management actions.

How to confirm the fix worked

Confirm that systems are running a kernel build from the vendor that contains the pm8916_lbc use-after-free fix. Validate exposure by checking whether the affected driver is present in the kernel source, module tree, kernel config, or runtime device bindings. Runtime checks may include looking for pm8916_lbc-related modules, platform-driver bindings, device-tree compatibility for Qualcomm PM8916 LBC, and kernel logs referencing the driver. After remediation, confirm that driver removal or shutdown paths no longer produce kernel warnings, KASAN use-after-free reports, oopses, or panics involving pm8916_lbc or extcon_set_state_sync(). In test environments only, exercise driver unbind/removal and charger interrupt scenarios to verify stability.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with the pm8916_lbc power-supply driver active.
2. Identify that the vulnerable driver is loaded or bound to the platform device.
3. Trigger driver teardown through unbind, module removal, device removal, reboot, suspend/resume, or another removal path available to the attacker.
4. Race the teardown with a charger, battery, or extcon-related interrupt so the IRQ handler runs after the extcon handle has been freed.
5. Cause extcon_set_state_sync() to operate on freed kernel memory.
6. Achieve a kernel crash or, with additional heap manipulation, attempt privilege escalation through kernel memory corruption.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, persistent system logs, crash dumps, pstore records, kdump/vmcore artifacts, audit logs, and EDR telemetry. Look for kernel oopses, panics, KASAN reports, or general-protection faults involving pm8916_lbc, extcon_set_state_sync(), extcon, IRQ handlers, or power-supply driver removal. Correlate crashes with recent writes to sysfs driver unbind/bind paths, module unload attempts, reboot or suspend/resume events, charger or battery connect/disconnect activity, and local user sessions. On systems with auditd, search for writes to /sys/bus/platform/drivers/*/unbind, execution of rmmod/modprobe, or administrative commands around the time of the crash. Because this bug most likely manifests as a local kernel crash, evidence may be limited to crash telemetry rather than durable application-level indicators.

• pm8916_lbc
• pm8916-lbc
• extcon_set_state_sync
• BUG: KASAN: use-after-free
• use-after-free in extcon_set_state_sync
• Unable to handle kernel paging request
• general protection fault
• kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• drivers/power/supply/pm8916_lbc.c
• /sys/bus/platform/drivers/pm8916-lbc/unbind
• /sys/bus/platform/drivers/pm8916_lbc/unbind
• /sys/bus/platform/drivers/*/unbind
• rmmod pm8916_lbc
• modprobe -r pm8916_lbc
• pm8916_lbc:
• power_supply
• extcon

What your security team should do

• Inventory Linux systems, embedded devices, mobile-derived platforms, appliances, and ARM/Qualcomm-based products that may include the pm8916_lbc driver.
• Prioritize patching systems where the affected driver is active and local users, containers with elevated device access, field technicians, or remote management users can trigger driver teardown or power-management actions.
• Update to the latest vendor-supported kernel containing the upstream fix; if no vendor package is available, track the distribution or device-vendor advisory for the backported patch.
• Harden local attack surfaces by limiting shell access, sudo privileges, module-management permissions, and write access to /sys driver bind/unbind controls.
• Enable or review kernel crash logging, persistent journald, kdump, pstore, auditd, and EDR telemetry for signs of kernel oopses or suspicious driver unbind/removal activity.
• Treat unexplained crashes involving pm8916_lbc, extcon_set_state_sync(), or KASAN use-after-free reports as potentially security-relevant until proven otherwise.
• Because this issue is not currently KEV-listed and EPSS is low, prioritize based on confirmed driver presence and system criticality rather than broad emergency response.