CVE-2022-49214
Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
26/02/2025
Última modificación:
26/02/2025
Descripción
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ágina incorrecta en los datos es de lectura o escritura") usamos page_fault_is_write(regs->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én conocidas como interrupciones de segmento de datos, no establecen DSISR (registro de estado de interrupción de almacenamiento de datos) en un valor útil. Todas las versiones de ISA desde la v2.03 hasta la v3.1 especifican que la interrupción 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ún contenido de BookIV. Esto se manifiesta como accesos que deberían ser de lectura que se informan incorrectamente como escrituras, por ejemplo, al usar el comando "dump" de xmon: 0:mon> 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ón de instrucción con fallas: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) en [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 Si desmontamos la PC, vemos una instrucción de carga: 0:mon> di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) También 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ún valor obsoleto en pt_regs de un error de página anterior. Reelabore la lógica de impresión 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> d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] ERROR: No se puede manejar el acceso a los datos del kernel en 0x5deadbeef0000000 [ 721.779697][ C6] Dirección de instrucción con error: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390] 0:mon> d 0 0000000000000000 [ 742.793242][ C6] ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 [ 742.793316][ C6] Instrucción con error dirección: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Acceso a datos SLB) en [c00000000ffbf390]