fkie_cve-2022-49214
Vulnerability from fkie_nvd
Published
2025-02-26 07:00
Modified
2025-02-26 07:00
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Don't use DSISR for SLB faults Since commit 46ddcb3950a2 ("powerpc/mm: Show if a bad page fault on data is read or write.") we use page_fault_is_write(regs->dsisr) in __bad_page_fault() to determine if the fault is for a read or write, and change the message printed accordingly. But SLB faults, aka Data Segment Interrupts, don't set DSISR (Data Storage Interrupt Status Register) to a useful value. All ISA versions from v2.03 through v3.1 specify that the Data Segment Interrupt sets DSISR "to an undefined value". As far as I can see there's no mention of SLB faults setting DSISR in any BookIV content either. This manifests as accesses that should be a read being incorrectly reported as writes, for example, using the xmon "dump" command: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [359526.415354][ C6] BUG: Unable to handle kernel data access on write at 0x5deadbeef0000000 [359526.415611][ C6] Faulting instruction address: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 If we disassemble the PC, we see a load instruction: 0:mon> di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) We can also see in exceptions-64s.S that the data_access_slb block doesn't set IDSISR=1, which means it doesn't load DSISR into pt_regs. So the value we're using to determine if the fault is a read/write is some stale value in pt_regs from a previous page fault. Rework the printing logic to separate the SLB fault case out, and only print read/write in the cases where we can determine it. The result looks like eg: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] BUG: Unable to handle kernel data access at 0x5deadbeef0000000 [ 721.779697][ C6] Faulting instruction address: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390] 0:mon> d 0 0000000000000000 [ 742.793242][ C6] BUG: Kernel NULL pointer dereference at 0x00000000 [ 742.793316][ C6] Faulting instruction address: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/093449bb182db885dae816d62874cccab7a4c42a
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/4a852ff9b7bea9c640540e2c1bc70bd3ba455d61
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/a3dae36d632b2cf6eb20314273e512a96cb43c9a
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d4679ac8ea2e5078704aa1c026db36580cc1bf9a
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/64s: Don\u0027t use DSISR for SLB faults\n\nSince commit 46ddcb3950a2 (\"powerpc/mm: Show if a bad page fault on data\nis read or write.\") we use page_fault_is_write(regs-\u003edsisr) in\n__bad_page_fault() to determine if the fault is for a read or write, and\nchange the message printed accordingly.\n\nBut SLB faults, aka Data Segment Interrupts, don\u0027t set DSISR (Data\nStorage Interrupt Status Register) to a useful value. All ISA versions\nfrom v2.03 through v3.1 specify that the Data Segment Interrupt sets\nDSISR \"to an undefined value\". As far as I can see there\u0027s no mention of\nSLB faults setting DSISR in any BookIV content either.\n\nThis manifests as accesses that should be a read being incorrectly\nreported as writes, for example, using the xmon \"dump\" command:\n\n  0:mon\u003e d 0x5deadbeef0000000\n  5deadbeef0000000\n  [359526.415354][    C6] BUG: Unable to handle kernel data access on write at 0x5deadbeef0000000\n  [359526.415611][    C6] Faulting instruction address: 0xc00000000010a300\n  cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400]\n      pc: c00000000010a300: mread+0x90/0x190\n\nIf we disassemble the PC, we see a load instruction:\n\n  0:mon\u003e di c00000000010a300\n  c00000000010a300 89490000      lbz     r10,0(r9)\n\nWe can also see in exceptions-64s.S that the data_access_slb block\ndoesn\u0027t set IDSISR=1, which means it doesn\u0027t load DSISR into pt_regs. So\nthe value we\u0027re using to determine if the fault is a read/write is some\nstale value in pt_regs from a previous page fault.\n\nRework the printing logic to separate the SLB fault case out, and only\nprint read/write in the cases where we can determine it.\n\nThe result looks like eg:\n\n  0:mon\u003e d 0x5deadbeef0000000\n  5deadbeef0000000\n  [  721.779525][    C6] BUG: Unable to handle kernel data access at 0x5deadbeef0000000\n  [  721.779697][    C6] Faulting instruction address: 0xc00000000014cbe0\n  cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]\n\n  0:mon\u003e d 0\n  0000000000000000\n  [  742.793242][    C6] BUG: Kernel NULL pointer dereference at 0x00000000\n  [  742.793316][    C6] Faulting instruction address: 0xc00000000014cbe0\n  cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64s: No usar DSISR para fallas SLB Desde el commit 46ddcb3950a2 (\"powerpc/mm: Mostrar si un fallo de p\u00e1gina incorrecta en los datos es de lectura o escritura\") usamos page_fault_is_write(regs-\u0026gt;dsisr) en __bad_page_fault() para determinar si el fallo es de lectura o escritura y cambiar el mensaje impreso en consecuencia. Pero las fallas SLB, tambi\u00e9n conocidas como interrupciones de segmento de datos, no establecen DSISR (registro de estado de interrupci\u00f3n de almacenamiento de datos) en un valor \u00fatil. Todas las versiones de ISA desde la v2.03 hasta la v3.1 especifican que la interrupci\u00f3n de segmento de datos establece DSISR \"en un valor indefinido\". Hasta donde puedo ver, tampoco se menciona que los fallos SLB establezcan DSISR en ning\u00fan contenido de BookIV. Esto se manifiesta como accesos que deber\u00edan ser de lectura que se informan incorrectamente como escrituras, por ejemplo, al usar el comando \"dump\" de xmon: 0:mon\u0026gt; d 0x5deadbeef0000000 5deadbeef0000000 [359526.415354][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en escritura en 0x5deadbeef0000000 [359526.415611][ C6] Direcci\u00f3n de instrucci\u00f3n con fallas: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) en [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 Si desmontamos la PC, vemos una instrucci\u00f3n de carga: 0:mon\u0026gt; di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) Tambi\u00e9n podemos ver en exceptions-64s.S que el bloque data_access_slb no establece IDSISR=1, lo que significa que no carga DSISR en pt_regs. Por lo tanto, el valor que estamos usando para determinar si el error es de lectura/escritura es alg\u00fan valor obsoleto en pt_regs de un error de p\u00e1gina anterior. Reelabore la l\u00f3gica de impresi\u00f3n para separar el caso de error de SLB y solo imprima lectura/escritura en los casos en los que podamos determinarlo. El resultado se parece a, por ejemplo: 0:mon\u0026gt; d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en 0x5deadbeef0000000 [ 721.779697][ C6] Direcci\u00f3n de instrucci\u00f3n con error: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390] 0:mon\u0026gt; d 0 0000000000000000 [ 742.793242][ C6] ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 [ 742.793316][ C6] Instrucci\u00f3n con error direcci\u00f3n: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390]"
    }
  ],
  "id": "CVE-2022-49214",
  "lastModified": "2025-02-26T07:00:58.490",
  "metrics": {},
  "published": "2025-02-26T07:00:58.490",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/093449bb182db885dae816d62874cccab7a4c42a"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/4a852ff9b7bea9c640540e2c1bc70bd3ba455d61"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/a3dae36d632b2cf6eb20314273e512a96cb43c9a"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d4679ac8ea2e5078704aa1c026db36580cc1bf9a"
    }
  ],
  "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.