CVE-2022-49214
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2022-49214
- Import Source
- https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-49214.json
- JSON Data
- https://api.osv.dev/v1/vulns/CVE-2022-49214
- Downstream
- Related
- Published
- 2025-02-26T01:55:49Z
- Modified
- 2025-10-21T10:15:29.193313Z
- Summary
- powerpc/64s: Don't use DSISR for SLB faults
- Details
-
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 pagefaultiswrite(regs->dsisr) in _badpagefault() 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 dataaccessslb block doesn't set IDSISR=1, which means it doesn't load DSISR into ptregs. So the value we're using to determine if the fault is a read/write is some stale value in ptregs 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
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- 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
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced46ddcb3950a28c0df4815e8dbb8d4b91d5d9f22dFixed4a852ff9b7bea9c640540e2c1bc70bd3ba455d61
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced46ddcb3950a28c0df4815e8dbb8d4b91d5d9f22dFixeda3dae36d632b2cf6eb20314273e512a96cb43c9a
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced46ddcb3950a28c0df4815e8dbb8d4b91d5d9f22dFixed093449bb182db885dae816d62874cccab7a4c42a
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduced46ddcb3950a28c0df4815e8dbb8d4b91d5d9f22dFixedd4679ac8ea2e5078704aa1c026db36580cc1bf9a