CVE-2026-46292

What it actually does

This Linux kernel flaw is a denial-of-service class bug in the generic PM domain (genpd) core. When a device is attached to a power-management domain through genpd_dev_pm_attach_by_id(), the kernel enables runtime power management for a corresponding virtual device. During detach, genpd_dev_pm_detach() failed to disable runtime PM. That leaves the virtual device in an inconsistent lifecycle state after it has been detached from its PM domain. In adverse timing or driver paths, subsequent runtime suspend handling can dereference invalid or NULL state in genpd_runtime_suspend(), causing a kernel NULL pointer dereference and system crash. In less severe cases, the bug can leave unnecessary performance-state votes active, causing incorrect power/performance behavior.

Why it matters to the business

The primary business risk is local system instability: affected Linux-based systems may crash, reboot, or behave unpredictably when drivers attach and detach virtual devices from generic power-management domains. This is most relevant to embedded systems, mobile/SoC platforms, appliances, and Linux deployments that rely heavily on runtime power management. There is no indication of known exploitation, CISA KEV listing, ransomware use, or mature public exploit activity, and the EPSS score is very low, so broad internet-scale attack risk appears limited. However, for products where uptime, power behavior, or device-driver reliability is critical, the operational impact can still be meaningful.

How an attack unfolds

An attacker would generally need a way to trigger driver or device-management behavior that causes a virtual device to be attached to and detached from a generic PM domain while runtime power-management callbacks remain active. After detach, the stale runtime PM enablement can cause the kernel to invoke genpd runtime suspend logic against a device that is no longer properly associated with its PM domain. If the vulnerable path is reached, genpd_runtime_suspend() may encounter missing domain state and trigger a NULL pointer dereference, leading to a kernel panic or system crash. This is not a typical remote code execution issue; practical exploitation is most likely local, device-specific, or dependent on access to interfaces that can exercise affected driver bind/unbind, power-state, or hotplug flows.

How to fix it

Apply a Linux kernel update that includes the upstream fix adding pm_runtime_disable() in genpd_dev_pm_detach(). Because no affected product list or exact fixed package versions were provided, use the corrected kernel from the relevant Linux distribution, device vendor, SoC vendor, or appliance vendor once available. For self-maintained kernels, backport the upstream pmdomain/core fix for the genpd detach procedure. If immediate patching is not possible, reduce exposure by limiting untrusted local access, restricting access to sysfs/debugfs or management interfaces that can bind/unbind drivers or manipulate device power states, disabling nonessential affected devices or drivers, and avoiding workflows that repeatedly attach/detach genpd-backed virtual devices. Test mitigations carefully on embedded or power-sensitive systems because disabling runtime power management or drivers may affect battery life, thermal behavior, or device functionality.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the vendor advisory, package changelog, kernel source, or applied patch set for the added pm_runtime_disable() call in genpd_dev_pm_detach(). On deployed systems, verify the active kernel version after reboot rather than only confirming that an updated package is installed. For custom kernels, inspect drivers/base/power/domain.c or the equivalent pmdomain core source and confirm detach paths disable runtime PM for virtual devices created through genpd_dev_pm_attach_by_id(). Functional validation should include exercising relevant device attach/detach, driver bind/unbind, suspend/resume, and runtime PM transitions while monitoring dmesg or journal logs for kernel oops, NULL pointer dereference, genpd_runtime_suspend errors, or unexpected reboots.

Typical attack path

1. Identify a Linux system or product using an affected kernel with generic PM domain support and drivers that attach virtual devices using genpd_dev_pm_attach_by_id().
2. Obtain local or otherwise privileged access to an interface capable of exercising affected device lifecycle operations, such as driver bind/unbind, device reset, hotplug, runtime power management, or platform-specific control paths.
3. Trigger attachment of a virtual device to a generic PM domain, causing runtime PM to be enabled for that virtual device.
4. Trigger detachment of the virtual device from the PM domain; on vulnerable kernels, runtime PM remains enabled after detach.
5. Cause or wait for runtime suspend handling to run against the detached virtual device.
6. Trigger a kernel NULL pointer dereference or related critical error in genpd_runtime_suspend(), resulting in a denial of service such as kernel panic, crash, or reboot.

How to detect it

This issue does not provide strong network-level indicators and is most likely observable through host crash and kernel logging. Review kernel logs, persistent journal records, crash dumps, console logs, pstore/ramoops, kdump/vmcore artifacts, and hardware watchdog reset records for evidence of NULL pointer dereferences or kernel panics involving genpd_runtime_suspend, generic PM domains, runtime PM, or pmdomain detach activity. Correlate crashes with preceding device lifecycle events such as driver bind/unbind operations, hotplug, device reset, suspend/resume, runtime PM transitions, or writes to sysfs power-control paths. On systems with auditd or EDR telemetry, look for processes writing to /sys/bus/*/drivers/*/bind, /sys/bus/*/drivers/*/unbind, /sys/devices/*/power/control, or related debugfs power-management controls shortly before a crash. Because no public exploit maturity or named threat actors are reported and EPSS is low, detection should focus on anomalous local activity and repeated crash patterns rather than external scanning.

• genpd_runtime_suspend
• NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• pmdomain
• genpd_dev_pm_detach
• genpd_dev_pm_attach_by_id
• pm_runtime_enable
• pm_runtime_disable
• /sys/bus/*/drivers/*/unbind
• /sys/bus/*/drivers/*/bind
• /sys/devices/*/power/control
• /sys/kernel/debug/pm_genpd
• ramoops
• /sys/fs/pstore
• vmcore

What your security team should do

• Inventory Linux kernels in products and fleets that use generic PM domains, especially embedded, mobile, IoT, appliance, and SoC-based platforms.
• Prioritize remediation for systems where local users, containers, device-management agents, or exposed management interfaces can influence driver lifecycle or power-management operations.
• Track distribution and vendor kernel advisories for this issue and deploy the first stable kernel containing the genpd detach fix.
• For custom or vendor-forked kernels, request or apply a backport of the pmdomain/core patch that adds pm_runtime_disable() during genpd device detach.
• Until patched, restrict untrusted access to sysfs/debugfs and administrative interfaces that can bind/unbind drivers, reset devices, or manipulate runtime power-management state.
• Monitor for kernel oops/panic events involving genpd_runtime_suspend, pmdomain, runtime PM, or NULL pointer dereferences, and treat repeated crashes as possible abuse or regression triggers.
• Include suspend/resume and runtime PM regression testing in validation for patched kernels to ensure the fix does not disrupt platform power behavior.