CVE-2022-49214
MEDIUMDescription
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]
Is your site exposed to CVE-2022-49214?
Run a free security scan — no signup, results in seconds.
CVSS v3.1 Score
Weakness Type (CWE)
Affected Products
| Vendor | Product |
|---|---|
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
References
Advisories & Patches
Frequently Asked Questions
What is CVE-2022-49214? +
How severe is CVE-2022-49214? +
What products are affected by CVE-2022-49214? +
How do I check if I'm vulnerable to CVE-2022-49214? +
Related Vulnerabilities
IEC 60870-5-104 used in bidirectional mode in RTU500 is vulnerable for a NULL pointer dereferencing, if a specially crafted sequence …
PAM-PKCS#11 is a Linux-PAM login module that allows a X.509 certificate based user login. In versions 0.6.12 and prior, the …
XZ Utils provide a general-purpose data-compression library plus command-line tools. In XZ Utils 5.3.3alpha to 5.8.0, the multithreaded .xz decoder …
A null pointer dereference vulnerability in the Palo Alto Networks Cortex® XDR agent on Windows devices allows a low-privileged local …
GNU Midnight Commander 4.8.29-146-g299d9a2fb was discovered to contain a NULL pointer dereference via the function x_error_handler() at tty/x11conn.c. NOTE: this …
A null pointer dereference vulnerability exists in the IOMap64.sys driver of ASUS AI Suite 3. The vulnerability can be triggered …