CVE-2024-42230: PowerPC pseries kexec race fix and impact

A small timing bug in the Linux kernel’s PowerPC pseries kexec path — tracked as CVE-2024-42230 — can cause a deterministic kernel crash during kexec on affected IBM Power systems, and upstream maintainers have changed the kexec sequence to prevent CPUs from executing the SCV instruction after AIL (reloc_on_exc) is disabled.

Background / Overview​

PowerPC’s pseries platform (used in IBM Power servers and LPAR virtualized guests) implements several architecture-specific mechanisms for transitioning between privilege levels and for rebooting into a different kernel image using kexec. The problem fixed in CVE-2024-42230 arises from a subtle sequencing error in that kexec path: the kernel disabled the AIL (Address‑Independent Loading / reloc_on_exc) mechanism too early — before all other CPUs had been halted — which left a window in which other CPUs could still execute the scv instruction. When scv executes without AIL in place, it causes an interrupt that lands at an unexpected (and unsupported) entry location in the kernel head code, producing an immediate kernel crash.
This is an availability-first issue: confidentiality and integrity are not affected by the bug itself, but the kernel crash leads to a denial-of-service condition for the host or guest. The public tracking databases record a CVSS v3.1 base score in the mid‑range (4.4), reflecting a combination of limited attack surface (local/adjacent) and high availability impact where the bug is reachable.

---

What exactly went wrong: technical deep dive​

The players: kexec, AIL, scv, and the fixed head code​

• kexec allows loading and jumping to a new kernel without going through firmware/bootloader, used for fast reboots and crash dump kernels.
• AIL (reloc_on_exc) is a platform/arch mechanism used to support certain real-mode behaviors — on pseries it is required so that the scv (supervisor call / special interrupt) instruction will be handled correctly by the head code.
• scv instruction on pseries triggers a real‑mode interrupt that expects to be serviced at a particular real-mode vector (notably, upstream notes that the real-mode scv interrupt vector resides at 0x17000, a high address the kernel head code historically did not support in its fixed-location setup).
• The fixed-location head code used by kexec (the early binary that runs before the relocated kernel is ready) is intentionally simple and cannot easily handle very high real-mode vectors, so correct sequencing around enabling/disabling relocations is critical.

The timing bug​

The bug is a race in the kexec shutdown sequence: the implementation disabled AIL early in the sequence — before all secondary CPUs were fully offline. If a secondary CPU executed an scv instruction during this window, the resulting real‑mode interrupt routed to an address the head code did not expect, causing an exception that crashed the kernel. The upstream fix reorders the kexec steps so that AIL is disabled only after other CPUs have been brought down and cannot issue scv — closing the race.
This is not a complex memory-corruption exploit; it’s a deterministic state / control-flow error that results in an immediate and reproducible kernel panic or oops when the scenario is hit under the right conditions. That makes it a reliable availability primitive in affected environments.

---

Affected systems and scope​

Multiple vulnerability trackers and vendor advisories list affected kernel ranges and distribution packages. Upstream stable kernel releases include fixes in the 6.1.98, 6.6.39, and 6.9.9 trees (and subsequent stable updates), and several downstream distributions have shipped backports or updated kernel packages that include the patch. Those distribution notices and kernel-stable commits are referenced by the security trackers and distro advisories.
Practical scope notes:

• The flaw only impacts PowerPC pseries builds of the Linux kernel. x86 and most ARM systems are not affected by this particular code path.
• kexec usage is required to trigger the problematic sequence; passive systems that never run kexec are not at risk from this exact bug.
• Environments that run kexec from privileged contexts (maintenance scripts, automated failover tooling, or cloud orchestration) are the most operationally exposed because kexec is often executed under administrative control.

Vendor advisories and distribution backports indicate this CVE was addressed in official kernels released in mid‑to‑late 2024 and in subsequent maintenance updates published by Linux distributors such as Debian, Ubuntu, SUSE, and others. System operators should consult their distro’s package changelog for the exact package versions that contain the fix.

---

Operational impact: why a “medium” score can still bite you hard​

CVE-2024-42230 is scored as medium (CVSS 4.4), but operational realities make the impact material in a subset of deployments:

• The exploit/trigger is local and usually requires elevated privileges (to run kexec), but many operational tools and automation stacks perform kexec as part of rolling updates, kernel patching, or provider-managed crash dump workflows. A single mis-scheduled or malformed kexec on a Power system could crash a host or guest unexpectedly during maintenance windows.
• In virtualized LPAR environments, kexec is sometimes used inside nested guests or orchestrated by platform-level tooling. The Ubuntu reproducibility notes demonstrate the kernel crash can be triggered in an LPAR guest when CPUs are selectively disabled then kexec is invoked. That means cloud or managed-service platforms using pseries hardware may see higher operational risk if they rely on kexec flows.
• Because the impact is immediate crash (availability), the real-world consequence can be severe for systems that perform critical workloads or host many tenants — even if the attack surface is relatively small.

In short: the mathematical CVSS score hides the fact that, for a narrow set of high‑value Power systems where kexec is used, the practical consequences can be significant.

---

Vendor response and patches​

Multiple independent sources and distro trackers confirm the upstream patch and the backports:

• The kernel community accepted a targeted patch that reorders the kexec shutdown sequence to disable AIL only after other CPUs are down. This commit was noted in kernel stable updates and referenced by the Debian security-tracker automation.
• Distributors have published fixes or packaged kernels that contain the upstream change. Ubuntu’s bug tracker details the backport and the test-plan used to reproduce the crash (disable CPUs, then use kexec -e with a target kernel); SUSE’s security update notes the same fix; Debian’s security automation includes the CVE with references to the stable commits. Operators should expect the fix to be present in the following kernel releases or later updates: 6.1.98, 6.6.39, 6.9.9 and the vendor-specific kernels that include those stable updates.

SUSE and other vendors explicitly list “powerpc/pseries: Fix scv instruction crash with kexec” in their kernel update bulletins, indicating distribution-level attention across the ecosystem.

---

Reproducing the condition (test plan / for maintainers)​

Ubuntu’s bug report includes step-by-step reproduction notes that are useful for kernel maintainers and operations teams performing validation in a lab:

• Boot an L1 LPAR or Power system image that runs a vulnerable kernel.
• Reduce the number of online CPUs (for example: use ppc64_cpu --cores-on=3 to leave some CPUs offline).
• Load the target kernel and initrd with kexec but perform an immediate kexec jump (kexec -l ...; kexec -e) using the “skip shutdown” path which causes the failing sequence to occur.
• Observe that the kernel crashes when scv executes after AIL is disabled.

These steps are intentionally specific because the issue manifests only in particular sequencing (disabled CPUs + kexec shortcut paths). Do not perform these tests in production; run them in a controlled lab or with permission on non-production hardware.

---

Mitigation and remediation guidance (practical checklist)​

Apply the patch as the primary remedy — update kernels to a fixed release or install your distributor’s security update. For operators who must triage quickly, use this checklist:

• Inventory and identify: Determine which hosts are PowerPC pseries and which kernel versions they run. Focus first on hosts running kernel lines earlier than the fixed stable releases (for example, kernels before 6.1.98, 6.6.39, 6.9.9 depending on your branch). Use package management and /proc/version to map affected systems.
• Patch: Upgrade the kernel to a version that includes the upstream fix or install your vendor’s security update. Confirm the package changelog mentions pseries/kexec or the CVE identifier if possible.
• For systems where kernel upgrades are not immediately possible, consider limiting or disabling kexec usage temporarily, especially any automated or user-exposed paths that invoke kexec. If you must allow kexec, restrict it to maintenance windows, and ensure no CPUs are disabled asymmetrically during the operation.
• Test: In a lab, validate the vendor kernel package by reproducing the Ubuntu test-case (only in controlled environments). Confirm that the earlier crash sequence no longer happens.
• Monitor: Watch for kernel oopses and panics in system logs and hypervisor management channels around times when kexec operations are performed. Audit orchestration tools and automation that could call kexec as part of image updates or crash handling.
• Coordinate with vendors/cloud providers: If you run workloads on managed platforms, confirm whether the provider’s images have been updated; if you’re a provider, schedule patch windows and notify tenants about potential kexec-related maintenance.

---

Risk assessment and practical recommendations​

• Attack feasibility: The bug requires the kexec sequence on pseries and the ability to influence when kexec runs with CPUs disabled; that typically requires administrative privileges or a privileged maintenance process. Therefore, the threat model is most concerning when multiple trust boundaries exist (for example, managed-tenant environments, multi-tenant LPARs, or scripts that run kexec without tight controls).
• Impact severity: High for availability in affected contexts. A single successful trigger produces an immediate kernel crash that can take the host or guest offline and may interrupt many services.
• Likelihood of exploitation in the wild: Low for general systems (because of platform specificity and privileged prerequisites), but realistically higher inside cloud, hosting, or telco environments where pseries hardware is used and kexec orchestration is common. No public proof‑of‑concepts were found in the open sources surveyed at the time of writing.
• Long-term risk posture: Low after patching. The fix is a small, surgical sequencing change and does not introduce new broad attack surfaces. Ensuring vendors and downstream distributions backport the change for long-term support kernels is the remaining operational task for many organizations.

---

Critical analysis: strengths and residual concerns​

Strengths of the upstream response​

• The kernel fix is surgical and conceptually straightforward: change the ordering in kexec to avoid the race. That reduces the risk of regressions and makes the patch easy to backport to stable branches. Multiple stable releases and distributions quickly referenced the change, demonstrating timely upstream triage.
• The problem is limited in scope to a single architecture and interface (pseries + kexec), simplifying distro testing and backport decisions.

Potential risks and residual issues​

• Operational blind spots: Many infrastructure teams treat kexec as a benign maintenance tool. Where orchestration or provider code calls kexec (for example, to install crash kernels or accelerate reboots), the assumption that the operation is always safe can lead to production interruptions. This CVE highlights that seemingly benign control paths deserve strict policy and testing.
• Backport coverage: Not all long‑term support or embedded kernels will receive timely backports. Organizations using custom kernels, embedded appliances, or vendor-supplied appliances that do not follow upstream stable updates should explicitly verify whether a vendor patch exists. Some vendors may not expose the CVE identifier in their release notes, requiring closer communication. Distribution advisories (Ubuntu, SUSE, Debian) do cover the issue, but bespoke systems are at risk until they incorporate the fix.
• Auditability: Because the vulnerability requires privileged operations to trigger, it could be overlooked in standard vulnerability scans that focus on network- or service-level exposures. Teams must include architecture-specific checks for Power systems when enumerating risk.

---

Detection and monitoring guidance​

• Monitor system logs for unexpected kernel oops/panic signatures around kexec activity windows. Kernel messages that reference real‑mode vectors or show immediate panics after kexec are strong indicators.
• Instrument orchestration flows that call kexec and add pre-checks: ensure all CPUs are in expected online/offline states before running kexec and verify post‑operation kernel state in automation.
• Add a compliance check for kernel versions on pseries hosts; treat any kernel older than the fixed stable releases as requiring immediate attention until patched. Use distribution package metadata to verify the presence of the security fix.

---

What defenders should tell management and customers​

• This is a targeted availability bug, not a data-exfiltration or privilege-escalation vulnerability — but it can cause complete service interruption on affected hosts if triggered.
• The vulnerability has been fixed upstream and by major distributors; for most installations this is resolved by standard kernel updates.
• The action required is straightforward: inventory Power systems, apply vendor kernel updates (or coordinate with vendors), and temporarily limit kexec usage where an immediate update is not possible.
• Communicate to operations teams that kexec is no longer a purely low‑risk maintenance primitive on affected pseries hosts and must be managed with stricter controls and QA.

---

Final thoughts​

CVE-2024-42230 is a classic example of how small sequencing mistakes in low-level platform code can produce outsized operational consequences. The bug’s footprint is narrow — PowerPC pseries kexec semantics — and the fix is simple and limited in scope, but the real-world impact can be severe in the narrow set of environments that both use pseries hardware and rely on kexec in production flows. That combination of narrow scope and high local impact is what makes these defects noteworthy: they’re easily missed by generic scanning yet can produce immediate outages when reached.
Operators running Power systems should prioritize patching, validate vendor backports for their long-term kernels, and treat kexec operations as privileged actions that belong behind stricter operational controls and testing. For defenders, the lesson extends beyond this specific CVE: maintain architecture-aware inventories, push minimal and targeted fixes quickly into long‑term support trees, and build test plans that exercise vendor-supplied maintenance paths like kexec before they run in production.

---

Conclusion: CVE-2024-42230 is an availability-focused kernel race that has been fixed upstream and by major distributions; patching and careful operational controls around kexec on Power systems are the correct and practical responses to eliminate the risk.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center