fkie_cve-2022-49955
Vulnerability from fkie_nvd
Published
2025-06-18 11:15
Modified
2025-06-18 13:46
Severity ?
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8b08d4f97233d8e58fff2fd9d5f86397a49733c5
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/91926d8b7e71aaf5f84f0cf208fc5a8b7a761050
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/rtas: Correcci\u00f3n del manejo de MSR[HV] de RTAS para Cell. Los cambios recientes en el manejo de MSR al ingresar RTAS (firmware) provocan bloqueos en las m\u00e1quinas IBM Cell. Ejemplo de rastreo: el kernel intent\u00f3 ejecutar la p\u00e1gina de usuario (2fff01a8): \u00bfintento de explotaci\u00f3n? (uid: 0) ERROR: No se puede controlar la obtenci\u00f3n de instrucciones del n\u00facleo Direcci\u00f3n de instrucci\u00f3n err\u00f3nea: 0x2fff01a8 Oops: Acceso del n\u00facleo al \u00e1rea defectuosa, firma: 11 [#1] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 M\u00f3dulos de celda NUMA vinculados: CPU: 0 PID: 0 Comm: swapper/0 Contaminado: GW 6.0.0-rc2-00433-gede0a8d3307a #207 NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 000000000000000 REGS: c0000000015236b0 TRAP: 0400 Contaminado: GW (6.0.0-rc2-00433-gede0a8d3307a) MSR: 0000000008001002  CR: 00000000 XER: 20000000 ... NIP 0x2fff01a8 LR 0x32608 Rastreo de llamadas: 0xc00000000143c5f8 (no confiable) .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 A diferencia de las plataformas PAPR, donde RTAS solo se usa en hu\u00e9spedes, en las m\u00e1quinas IBM Cell, Linux se ejecuta con MSR[HV] activado, pero tambi\u00e9n usa RTAS, proporcionado por SLOF. Para solucionarlo, copie el bit MSR[HV] del valor MSR que acabamos de leer con mfmsr al valor usado para RTAS. Parece que tambi\u00e9n podr\u00edamos solucionarlo usando un #ifdef CELL para activar MSR[HV], pero esto no funciona, ya que es posible crear una \u00fanica imagen de kernel que funcione tanto en Cell nativo como en pseries."
    }
  ],
  "id": "CVE-2022-49955",
  "lastModified": "2025-06-18T13:46:52.973",
  "metrics": {},
  "published": "2025-06-18T11:15:22.630",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/8b08d4f97233d8e58fff2fd9d5f86397a49733c5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/91926d8b7e71aaf5f84f0cf208fc5a8b7a761050"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.