CVE-2022-49214 in Linux
Summary
by MITRE • 02/26/2025
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]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 02/16/2026
The vulnerability described in CVE-2022-49214 affects the Linux kernel's handling of page faults on PowerPC 64s architectures, specifically impacting how the kernel determines whether a memory access fault is a read or write operation. This flaw stems from an incorrect assumption in the kernel's memory management subsystem where the DSISR (Data Storage Interrupt Status Register) value is used to distinguish between read and write page faults. The issue manifests when SLB (Segment Lookaside Buffer) faults occur, which are a specific category of data access interruptions that do not properly set the DSISR register to a meaningful value according to PowerPC architecture specifications.
The technical root cause of this vulnerability lies in the kernel's __bad_page_fault() function which relies on page_fault_is_write(regs->dsisr) to determine fault type. When SLB faults occur, the DSISR register contains an undefined value as specified in PowerPC ISA versions 2.03 through 3.1, yet the kernel code attempts to use this stale register value to classify the fault type. This leads to incorrect reporting where read operations are incorrectly classified as write operations, causing misleading error messages during kernel debugging sessions. The problem is particularly evident when using kernel debugging tools like xmon where commands such as "dump" trigger these faulty classifications.
The operational impact of this vulnerability extends beyond simple misclassification of fault types, as it can confuse kernel debugging and analysis efforts, potentially masking the true nature of memory access violations. This misclassification affects the kernel's ability to provide accurate diagnostic information during system crashes or debugging sessions, making it more difficult for developers and system administrators to properly identify and resolve memory-related issues. The vulnerability specifically impacts PowerPC 64s systems where the kernel attempts to handle SLB faults, which are data segment interrupts that occur when accessing memory that does not have a valid segment table entry.
The fix implemented addresses this issue by reworking the printing logic to explicitly separate SLB fault cases from regular page faults, ensuring that read/write determination only occurs in situations where the DSISR value is actually meaningful. This approach aligns with security best practices for kernel debugging and fault handling, as outlined in various cybersecurity frameworks and security standards. The solution prevents the kernel from making incorrect assumptions about fault types based on undefined register values, thereby improving the reliability and accuracy of kernel error reporting. This vulnerability demonstrates the importance of proper register value validation in kernel-level code and highlights how architectural specifications must be carefully considered when implementing memory management subsystems. The fix ensures that error messages accurately reflect the actual nature of memory access violations while maintaining proper kernel functionality for legitimate page fault handling operations.
This vulnerability classification aligns with CWE-252, which deals with "Unchecked Return Value" and CWE-476, "NULL Pointer Dereference," as the incorrect handling of undefined DSISR values can lead to misleading error reporting and potentially impact system stability. The issue also relates to ATT&CK technique T1059.003, "Command and Scripting Interpreter: Windows Command Shell," in kernel contexts where debugging commands produce incorrect output due to faulty error reporting mechanisms. The fix represents a defensive programming approach that validates register state before making assumptions about fault characteristics, which is consistent with security engineering principles and kernel security hardening practices recommended by industry standards.