ghsa-8jrg-738q-v5mw
Vulnerability from github
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]
{
"affected": [],
"aliases": [
"CVE-2022-49214"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:58Z",
"severity": "MODERATE"
},
"details": "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]",
"id": "GHSA-8jrg-738q-v5mw",
"modified": "2025-09-22T21:30:15Z",
"published": "2025-09-22T21:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49214"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/093449bb182db885dae816d62874cccab7a4c42a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a852ff9b7bea9c640540e2c1bc70bd3ba455d61"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3dae36d632b2cf6eb20314273e512a96cb43c9a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4679ac8ea2e5078704aa1c026db36580cc1bf9a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.