{"cve":"CVE-2022-49214","nvd":{"published":"2025-02-26T07:00:58.490","modified":"2026-06-17T05:17:24.400","status":"Analyzed","description":"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]","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":["CWE-476"],"references":["https://git.kernel.org/stable/c/093449bb182db885dae816d62874cccab7a4c42a","https://git.kernel.org/stable/c/4a852ff9b7bea9c640540e2c1bc70bd3ba455d61","https://git.kernel.org/stable/c/a3dae36d632b2cf6eb20314273e512a96cb43c9a","https://git.kernel.org/stable/c/d4679ac8ea2e5078704aa1c026db36580cc1bf9a"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T21:59:48.811064707+00:00"},"epss":{"cve":"CVE-2022-49214","score":0.00268,"percentile":0.19037,"date":"2026-10-31"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}