CVE-2026-45968

What it actually does

This is a Linux kernel denial-of-service flaw in the cpuidle subsystem. On platforms where only one CPU idle state is registered, specifically cases where that state is a polling state, the ladder idle governor can incorrectly select an out-of-bounds idle-state index. That invalid selection can result in the kernel attempting to call a NULL idle-state enter callback, causing a kernel fault and system crash. The impact is availability loss; the vulnerability does not directly provide confidentiality or integrity compromise.

Why it matters to the business

Affected systems can crash unexpectedly, causing service interruption, workload disruption, failover events, or downtime for applications running on impacted Linux hosts. The risk is most relevant to specific hardware/platform configurations, such as PowerNV systems without the expected power-management device-tree node. Because exploitation requires local privileges and there is no known public exploitation or CISA KEV listing, urgency is lower than for remotely exploitable vulnerabilities, but affected production systems should still be patched during the next appropriate maintenance window to prevent avoidable outages.

How an attack unfolds

An attacker would first need local access to an affected Linux system with enough ability to run code or influence CPU idle behavior. On a vulnerable platform where cpuidle has registered only a single idle state, the kernel may enter the cpuidle selection path during normal CPU idle transitions. The ladder governor can mis-handle the single-state case and attempt to use an idle-state index that is not valid. When the kernel later tries to enter that idle state, it can dereference a NULL enter callback and crash. In practice, exploitation is a local availability attack: the attacker’s goal is to trigger the vulnerable idle path reliably enough to panic or crash the host, rather than to execute code or escalate privileges.

How to fix it

Upgrade to a Linux kernel version that includes the cpuidle fix which bypasses the governor when state_count is less than or equal to 1 and directly returns state 0. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution, vendor, or upstream stable kernel branch once available. Prioritize systems matching the affected platform profile, especially PowerNV hosts where logs indicate only the Snooze idle state is available. If immediate patching is not possible, reduce exposure by limiting local shell or workload execution access to trusted users, enforcing least privilege, and monitoring affected systems for cpuidle-related crashes. Operational mitigations may also include testing alternate kernel boot parameters or platform firmware/device-tree configuration changes recommended by the hardware or OS vendor, but these should be validated carefully because idle-management changes can affect power and performance behavior.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is a vendor-fixed build containing the cpuidle single-state bail-out behavior. Review vendor advisories, package changelogs, or kernel commit history for the cpuidle change described as skipping the governor when only one idle state is available. On potentially affected systems, check boot logs for cpuidle registration messages such as only one idle state being available, then validate that the system no longer crashes during idle transitions after applying the update. Use controlled testing in a staging environment that matches the affected hardware profile before broad production rollout. Also confirm that crash dumps or kernel logs no longer show NULL instruction-pointer faults associated with cpuidle_enter_state.

Typical attack path

1. Gain local access to an affected Linux system, such as through a shell, compromised account, or local workload execution context.
2. Confirm or rely on a vulnerable platform configuration where cpuidle has only one available idle state, particularly a polling state.
3. Create conditions that cause CPUs to transition through the cpuidle selection path, such as periods of idleness or CPU activity followed by idle transitions.
4. Trigger the ladder governor’s incorrect idle-state selection for a single-state cpuidle configuration.
5. Cause the kernel to invoke a NULL idle-state enter callback, leading to a kernel crash or system reboot.

How to detect it

To determine whether this issue may have already caused outages, review kernel logs, persistent journal entries, console logs, crash dumps, and hardware management logs for cpuidle-related faults or unexplained reboots. Focus on messages during boot or shortly before a crash that indicate only one idle state was registered, followed by a NULL instruction-pointer fault or stack trace involving cpuidle_enter_state, cpuidle_select, the ladder governor, or cpuidle-powernv. On systemd-based systems, search `journalctl -k` and prior-boot journals using `journalctl -k -b -1`, `-b -2`, and so on. On systems using traditional logs, review `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, and crash dump locations such as `/var/crash`. Because this is a local denial-of-service condition, there may be no network IOC. Correlate crash timing with local user sessions, scheduled jobs, container workload activity, or newly deployed local code that could have increased idle-state transitions. There are no known named threat actors or ransomware campaigns associated with this vulnerability based on the provided data.

• cpuidle-powernv : Only Snooze is available
• Faulting instruction address: 0x00000000
• NIP [0000000000000000] 0x0
• cpuidle_enter_state+0x2c4/0x668
• cpuidle_enter_state
• cpuidle_select
• Only Snooze is available
• NULL enter callback
• /var/crash
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux systems running on PowerNV or other platforms with unusual cpuidle configurations, and identify those with vulnerable kernel versions.
• Prioritize patching affected production hosts where an unexpected reboot would cause service disruption, even though exploitation requires local access.
• Restrict local access and untrusted workload execution on potentially affected systems until fixed kernels are deployed.
• Monitor kernel logs, crash dumps, and system reboot events for cpuidle-related NULL pointer faults or messages indicating only one idle state is available.
• Validate the vendor-fixed kernel in staging on representative hardware before production rollout, especially for systems sensitive to power-management behavior.
• Track distribution and hardware-vendor advisories for exact fixed package versions and any recommended firmware or device-tree updates.