CVE-2022-49214

{"id": "CVE-2022-49214", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2025-02-26T07:00:58.490", "references": [{"url": "https://git.kernel.org/stable/c/093449bb182db885dae816d62874cccab7a4c42a", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/4a852ff9b7bea9c640540e2c1bc70bd3ba455d61", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a3dae36d632b2cf6eb20314273e512a96cb43c9a", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d4679ac8ea2e5078704aa1c026db36580cc1bf9a", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-476"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/64s: Don't 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->dsisr) 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't 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's 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> 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> 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't set IDSISR=1, which means it doesn't load DSISR into pt_regs. So\nthe value we're 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> 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> 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->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> 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> 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> 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> 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]"}], "lastModified": "2025-09-22T20:59:54.547", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "D12E24E0-E6F9-4B01-A775-2EE02EEAE1E9", "versionEndExcluding": "5.15.33", "versionStartIncluding": "5.5"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "20C43679-0439-405A-B97F-685BEE50613B", "versionEndExcluding": "5.16.19", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "210C679C-CF84-44A3-8939-E629C87E54BF", "versionEndExcluding": "5.17.2", "versionStartIncluding": "5.17"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}