ghsa-q32g-q8h6-hf4v
Vulnerability from github
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 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.
{
"affected": [],
"aliases": [
"CVE-2022-49955"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:22Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/rtas: Fix RTAS MSR[HV] handling for Cell\n\nThe semi-recent changes to MSR handling when entering RTAS (firmware)\ncause crashes on IBM Cell machines. An example trace:\n\n kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)\n BUG: Unable to handle kernel instruction fetch\n Faulting instruction address: 0x2fff01a8\n Oops: Kernel access of bad area, sig: 11 [#1]\n BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell\n Modules linked in:\n CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.0.0-rc2-00433-gede0a8d3307a #207\n NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 0000000000000000\n REGS: c0000000015236b0 TRAP: 0400 Tainted: G W (6.0.0-rc2-00433-gede0a8d3307a)\n MSR: 0000000008001002 \u003cME,RI\u003e CR: 00000000 XER: 20000000\n ...\n NIP 0x2fff01a8\n LR 0x32608\n Call Trace:\n 0xc00000000143c5f8 (unreliable)\n .rtas_call+0x224/0x320\n .rtas_get_boot_time+0x70/0x150\n .read_persistent_clock64+0x114/0x140\n .read_persistent_wall_and_boot_offset+0x24/0x80\n .timekeeping_init+0x40/0x29c\n .start_kernel+0x674/0x8f0\n start_here_common+0x1c/0x50\n\nUnlike PAPR platforms where RTAS is only used in guests, on the IBM Cell\nmachines Linux runs with MSR[HV] set but also uses RTAS, provided by\nSLOF.\n\nFix it by copying the MSR[HV] bit from the MSR value we\u0027ve just read\nusing mfmsr into the value used for RTAS.\n\nIt seems like we could also fix it using an #ifdef CELL to set MSR[HV],\nbut that doesn\u0027t work because it\u0027s possible to build a single kernel\nimage that runs on both Cell native and pseries.",
"id": "GHSA-q32g-q8h6-hf4v",
"modified": "2025-06-18T12:30:37Z",
"published": "2025-06-18T12:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49955"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b08d4f97233d8e58fff2fd9d5f86397a49733c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/91926d8b7e71aaf5f84f0cf208fc5a8b7a761050"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.