CVE-2022-49955: powerpc/rtas: Fix RTAS MSR[HV] handling for Cell
In the Linux kernel, the following vulnerability has been resolved:
powerpc/rtas: Fix RTAS MSR[HV] handling for Cell
The semi-recent changes to MSR handling when entering RTAS (firmware)
cause crashes on IBM Cell machines. An example trace:
kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch
Faulting instruction address: 0x2fff01a8
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.0.0-rc2-00433-gede0a8d3307a #207
NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 0000000000000000
REGS: c0000000015236b0 TRAP: 0400 Tainted: G W (6.0.0-rc2-00433-gede0a8d3307a)
MSR: 0000000008001002 <ME,RI> CR: 00000000 XER: 20000000
...
NIP 0x2fff01a8
LR 0x32608
Call Trace:
0xc00000000143c5f8 (unreliable)
.rtas_call+0x224/0x320
.rtas_get_boot_time+0x70/0x150
.read_persistent_clock64+0x114/0x140
.read_persistent_wall_and_boot_offset+0x24/0x80
.timekeeping_init+0x40/0x29c
.start_kernel+0x674/0x8f0
start_here_common+0x1c/0x50
Unlike PAPR platforms where RTAS is only used in guests, on the IBM Cell
machines Linux runs with MSR[HV] set but also uses RTAS, provided by
SLOF.
Fix it by copying the MSR[HV] bit from the MSR value we've just read
using mfmsr into the value used for RTAS.
It seems like we could also fix it using an #ifdef CELL to set MSR[HV],
but that doesn't work because it's possible to build a single kernel
image that runs on both Cell native and pseries.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel powerpc issue affecting IBM Cell systems using RTAS firmware. A kernel change mishandled the hypervisor bit in the machine state register before RTAS calls, causing crashes. The public record does not show remote exploitation, data theft, privilege escalation, or broad cloud impact.
Executive priority
Low broad-enterprise urgency unless the organization operates IBM Cell or related powerpc Linux systems. For affected environments, treat as an availability and stability fix, with priority based on system criticality.
Technical view
On Cell, Linux can run with MSR[HV] set while still calling RTAS supplied by SLOF. A prior RTAS entry path failed to preserve that HV state, leading to bad instruction fetches and kernel oopses. The fix copies MSR[HV] from the current MSR into the RTAS MSR value.
Likely exposure
Exposure appears limited to Linux on IBM Cell or compatible powerpc systems using RTAS. Most x86, ARM, ordinary cloud, and non-Cell Linux deployments are not indicated as affected by the provided sources.
Exploitation context
CISA KEV is false, and the provided sources do not report active exploitation. The evidence describes crash behavior on specific hardware, not a public exploit chain or attacker workflow.
Researcher notes
The record lacks CVSS, CWE, exploit prerequisites, and detailed affected downstream packages. The clearest impact is a kernel crash from incorrect RTAS MSR[HV] handling on Cell. Avoid assuming confidentiality or privilege impact without additional vendor evidence.
Mitigation direction
Identify any Linux powerpc Cell systems in asset inventory.
Review kernel version and vendor advisories for CVE-2022-49955.
Update to a kernel containing the referenced stable fixes.
Prioritize affected production or availability-sensitive Cell systems.
Monitor vendor guidance if using downstream Linux distributions.
Validation and detection
Confirm whether any fleet systems run Linux on IBM Cell hardware.
Check kernel package changelogs for CVE-2022-49955 or the stable commit IDs.
Review boot and kernel logs for RTAS-related oopses on affected hardware.
Verify patched systems boot and perform RTAS timekeeping paths normally.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-49955 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
3Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jun 18, 2025, 11:00 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.