mirror of
https://github.com/fkie-cad/nvd-json-data-feeds.git
synced 2025-05-31 02:31:22 +00:00
33 lines
3.2 KiB
JSON
33 lines
3.2 KiB
JSON
![]() |
{
|
||
|
"id": "CVE-2022-49214",
|
||
|
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
|
||
|
"published": "2025-02-26T07:00:58.490",
|
||
|
"lastModified": "2025-02-26T07:00:58.490",
|
||
|
"vulnStatus": "Received",
|
||
|
"cveTags": [],
|
||
|
"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]"
|
||
|
}
|
||
|
],
|
||
|
"metrics": {},
|
||
|
"references": [
|
||
|
{
|
||
|
"url": "https://git.kernel.org/stable/c/093449bb182db885dae816d62874cccab7a4c42a",
|
||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||
|
},
|
||
|
{
|
||
|
"url": "https://git.kernel.org/stable/c/4a852ff9b7bea9c640540e2c1bc70bd3ba455d61",
|
||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||
|
},
|
||
|
{
|
||
|
"url": "https://git.kernel.org/stable/c/a3dae36d632b2cf6eb20314273e512a96cb43c9a",
|
||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||
|
},
|
||
|
{
|
||
|
"url": "https://git.kernel.org/stable/c/d4679ac8ea2e5078704aa1c026db36580cc1bf9a",
|
||
|
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
|
||
|
}
|
||
|
]
|
||
|
}
|