CVE-2022-34331 is a security vulnerability discovered in IBM Power Systems relating to how SRIOV (Single Root I/O Virtualization) network adaptors are managed after certain firmware maintenance procedures. If you are running IBM Power Systems with Power firmware levels FW950 or FW101 and use SRIOV adapters, you might be exposed to a network isolation risk. IBM X-Force ID: 229695 has catalogued this bug and recommends immediate action.
In this article I’ll walk you through what this bug is, how it could be abused, and give you practical insight—plus code snippets—for detecting and fixing it.
What’s the Issue?
Short version:
After running a series of SRIOV maintenance steps—like adapter initialize, activate, and logical port configuration (common in update or troubleshooting tasks)—the system can fail to re-apply your desired VEPA (Virtual Ethernet Port Aggregator) setting. Instead, VEPA gets *disabled*, potentially breaking network segmentation: all SR-IOV Logical Ports (LPARs) might be able to see each other’s traffic directly, exposing sensitive information and making the system easier to attack laterally.
IBM’s Advisory (Original Reference)
- IBM Security Bulletin for CVE-2022-34331
- NVD CVE-2022-34331 Details
Systems:
- Any with SRIOV support and network segmentation/VEPA configured.
How Attackers Could Exploit This
Suppose your company segments workloads so that your HR and IT servers can't see each other's network traffic, using VEPA enforced by SRIOV.
If an attacker gets access to the system and can trigger or simulate a maintenance sequence (even unintentionally—like during firmware updates!), the system could clear out your VEPA settings:
The SRIOV Logical Ports are reconfigured, but the “VEPA enabled” flag is *not* restored.
3. All LPARs connected via that adapter now have “VEPA disabled”—so they appear on the same network segment.
Exploit Scenario Example
Let’s show a simulated PowerShell-like sequence (assuming remote access to system with PowerShell remoting for the sake of illustration; on actual systems, IBM “padmin” shell or HMC CLI is used):
# Before maintenance, confirm VEPA is enabled on certain logical ports:
lsdev -C | grep 'SRIOV'
lsattr -El entX | grep vepa
# Maintenance is performed...
# After maintenance, attacker checks SRIOV port state:
lsattr -El entX | grep vepa
# Output: vepa
# Now, attacker can use tcpdump (or similar) inside a different LPAR to sniff traffic:
tcpdump -i eth
# Data from another partition appears, breaking segmentation.
Use the IBM AIX command line to verify VEPA status on SRIOV logical ports
for ent in $(lsdev -C | grep SRIOV | awk '{print $1}'); do
echo "Device: $ent"
lsattr -El $ent | grep vepa
done
A “vepa ” output means VEPA is *disabled*.
1. Update Firmware
IBM has patched the bug in later firmware levels. Upgrade as soon as feasible; for guidance, check the IBM Fix Central.
After *every* maintenance sequence, confirm and (if needed) re-enable VEPA
chattr -E -l entX -a vepa=1
Repeat for all logical ports that should have VEPA on.
Consider a regular job (cron) to catch accidental VEPA disabling
crontab -e
# Add:
*/15 * * * * /usr/local/bin/check_vepa.sh
/usr/local/bin/check_vepa.sh
#!/bin/bash
for ent in $(lsdev -C | grep SRIOV | awk '{print $1}'); do
vepa=$(lsattr -El $ent | awk '/vepa/ {print $2}')
if [ "$vepa" -eq ]; then
logger "Warning: VEPA is disabled on $ent"
chattr -E -l $ent -a vepa=1
fi
done
Summary
CVE-2022-34331 is a subtle, dangerous issue if you depend on network segmentation via SRIOV adapters on IBM Power Systems. The real risk is that maintenance tasks—supposed to keep your system safe—can accidentally make it *less* secure. Without robust detection and remediation, all the walls between your LPARs may vanish unnoticed.
Fixes:
Patch firmware
- Reapply/verify VEPA
Automate regular checks
Don’t wait until after an audit or a breach—fix it now!
More information
- IBM X-Force ID: 229695
- IBM PowerVM SR-IOV Overview
Stay safe—watch those post-maintenance settings!
Timeline
Published on: 11/11/2022 18:15:00 UTC
Last modified on: 11/17/2022 14:42:00 UTC