CVE-2026-17503: IBM Power System S1122 DoS Vulnerability

CVE-2026-17503 Overview

CVE-2026-17503 is a local integrity and availability flaw in IBM PowerVM Hypervisor firmware. The affected firmware streams are FW1120.00 through FW1120.01, FW1110.00 through FW1110.31, FW1060.00 through FW1060.81, and FW950.00 through FW950.H3. An attacker with root access inside a logical partition (LPAR) can alter the partition's NVRAM in a way that the partition firmware cannot process at boot. The impacted LPAR then fails to boot and remains unusable until an operator deletes and recreates the partition configuration. The issue is tracked under [CWE-20] Improper Input Validation and affects a broad range of IBM Power Systems hardware.

Critical Impact
A root-level user in a single partition can permanently brick that LPAR's boot path, forcing manual destruction and recreation of the partition to restore service.

Affected Products

IBM PowerVM Hypervisor firmware FW1120.00 through FW1120.01
IBM PowerVM Hypervisor firmware FW1110.00 through FW1110.31, and FW1060.00 through FW1060.81
IBM PowerVM Hypervisor firmware FW950.00 through FW950.H3 running on Power9/Power10 systems (E980, E1080, E1180, S922, S924, S1014, S1022, S1024, S1012, L1022, L1024, E1050, E1150, S1112, S1114, S1122, S1124, L1122, L1124, and related models)

Discovery Timeline

2026-09-24 - CVE-2026-17503 published to NVD
2026-09-30 - Last updated in NVD database

Technical Details for CVE-2026-17503

Vulnerability Analysis

The flaw resides in the partition firmware runtime boot configuration logic of the PowerVM Hypervisor. PowerVM virtualizes IBM Power Systems hardware and maintains per-LPAR non-volatile RAM (NVRAM) to store boot variables and configuration. The partition firmware trusts the content of this NVRAM when preparing the next boot. Because the firmware does not fully validate NVRAM structures written from inside the guest, a privileged guest process can place crafted data in NVRAM that the firmware cannot parse. On the next boot, the partition halts rather than booting the operating system. Recovery requires an administrator on the Hardware Management Console (HMC) to delete and recreate the partition profile, which also discards any customized NVRAM state. The exploit path is local to the partition and requires high privileges, but the resulting outage is persistent across reboots.

Root Cause

The underlying weakness is Improper Input Validation [CWE-20] on NVRAM content consumed by the partition firmware during the boot path. The firmware accepts guest-authored NVRAM values without sufficient structural validation, so malformed data persists and is reprocessed on every subsequent boot attempt.

Attack Vector

An attacker must first obtain root privileges inside a target LPAR, typically through compromise of a workload running on AIX, IBM i, or Linux on Power. From that foothold, the attacker writes malicious data into partition NVRAM using standard operating system interfaces for firmware variables. The partition continues to run normally until it is rebooted. On the next boot, the firmware fails to process the altered NVRAM and the LPAR cannot start, producing a denial-of-service condition that only operator intervention can clear.

Detection Methods for CVE-2026-17503

Indicators of Compromise

Unexpected writes to partition NVRAM or firmware variables from guest userland, especially outside of planned maintenance windows.
LPARs that transition from Running to a failed boot state on restart and cannot complete the firmware boot phase.
HMC events indicating partition boot failures across multiple reboot attempts for a previously healthy LPAR.

Detection Strategies

Monitor root-level process activity inside each LPAR for use of NVRAM access tools such as nvram, nvsetenv, or direct writes to /dev/nvram and firmware variable interfaces.
Correlate privileged shell activity with subsequent HMC-reported boot failures to identify likely tampering versus hardware faults.
Baseline normal firmware variable changes per workload so that out-of-band modifications stand out in telemetry.

Monitoring Recommendations

Forward HMC and PowerVM service event logs into a central SIEM and alert on repeated partition boot failures.
Audit and log all administrative sessions on LPARs, including commands executed as root, and retain the data for post-incident review.
Track firmware version inventory for every managed Power system to confirm that patched FW levels are deployed consistently.

How to Mitigate CVE-2026-17503

Immediate Actions Required

Apply the fixed PowerVM Hypervisor firmware level published in the IBM advisory to all affected Power Systems during the next change window.
Restrict and review root access inside LPARs; limit interactive root logins and enforce multi-person approval for privileged changes.
Capture current partition profiles and NVRAM configuration on the HMC so that an LPAR can be rebuilt quickly if it is bricked.

Patch Information

IBM has published remediation guidance and fixed firmware levels in the vendor advisory. Refer to the IBM Support Page for CVE-2026-17503 for the exact FW service pack that corresponds to each affected stream (FW1120, FW1110, FW1060, and FW950) and for installation instructions through the HMC.

Workarounds

Reduce the number of workloads that run with persistent root privileges and require just-in-time elevation for firmware-level operations.
Segment management networks so that only authorized administrators can reach the HMC and partition consoles.
Maintain tested backups of LPAR profiles and boot configurations so that recreating a partition after exploitation is a routine, low-risk operation.

bash

# Example: review current PowerVM firmware level from the HMC
lssyscfg -r sys -F name,type_model,serial_num,state
lslic -t sys -m <managed-system-name> -F activated_level,installed_level,accepted_level

# Stage and apply the fixed service pack referenced in the IBM advisory
updlic -o d -t sys -l latest -m <managed-system-name> -r mountpoint -d /mnt/fwfix
updlic -o a -t sys -m <managed-system-name>