CVE-2021-47034 in Linux
Summary
by MITRE • 02/28/2024
In the Linux kernel, the following vulnerability has been resolved:
powerpc/64s: Fix pte update for kernel memory on radix
When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised.
radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region.
However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults.
As the code patching is done using __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen:
BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module]
CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1
This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/[email protected]/
Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) &
Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like:
ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------
ftrace failed to modify [] napi_busy_loop+0xc/0x390
actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here ]------------
WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module]
CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033 CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call T ---truncated---
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/31/2024
The vulnerability CVE-2021-47034 affects the Linux kernel's powerpc architecture implementation, specifically within the radix memory management unit handling. This flaw stems from an insufficient memory ordering mechanism during page table entry updates for kernel memory regions. The core issue manifests in the radix__set_pte_at() function which omits the ptesync instruction necessary to order PTE updates with subsequent memory accesses. While this optimization is acceptable for user-space memory where page fault handlers can correct spurious faults, kernel memory faults cannot be handled in the same manner, leading to critical system instability. The vulnerability specifically impacts systems using Strict RWX (Read-Write-Execute) protections combined with radix MMU implementation, creating a race condition between PTE setting and memory access operations.
The technical flaw occurs when mapping kernel pages through map_kernel_page() function, which fails to invoke flush_cache_vmap() as required for proper cache coherency. This omission becomes particularly problematic during code patching operations, such as those performed by do_patch_instruction() function. When patching instructions, the system maps the page frame containing the target instruction and immediately writes to it without proper memory ordering. The use of __put_user_asm_goto() in the patching process obscures the underlying fault condition, making detection more difficult compared to normal store operations that generate clear fault traces. The vulnerability essentially allows for memory access violations that result in kernel oops and system crashes, particularly when ftrace (function tracing) is actively modifying code paths.
The operational impact of this vulnerability is severe as it can lead to system crashes, kernel oops, and data corruption during normal operation. The issue is particularly dangerous in environments using dynamic code patching or function tracing, where the vulnerability manifests within minutes of system operation. The crash traces show kernel access violations at specific memory addresses, indicating that the system attempts to access kernel memory locations that have not been properly synchronized with the page table updates. This vulnerability affects systems running kernel versions 5.10.0-rc5 and later, particularly those using PowerPC architecture with radix MMU and Strict RWX protections. The vulnerability can be reliably reproduced through ftrace toggling operations, which perform extensive code patching and trigger the memory ordering race condition.
Mitigation strategies for CVE-2021-47034 involve ensuring proper memory ordering during kernel memory page table updates. The primary fix requires modifying the map_kernel_page() function to properly call flush_cache_vmap() or equivalent cache synchronization mechanisms before allowing subsequent memory access operations. This approach aligns with the established ATT&CK framework's defense evasion techniques by ensuring proper memory synchronization during code modification operations. The solution must maintain performance characteristics while providing necessary memory ordering guarantees. System administrators should apply the relevant kernel patches immediately, particularly on systems using ftrace functionality or dynamic code patching. Additionally, monitoring for kernel oops and memory access violations during code modification operations can help detect potential exploitation attempts. The vulnerability demonstrates the importance of proper memory ordering in kernel space operations, particularly when dealing with memory management unit implementations that require strict cache coherency protocols. This issue relates to CWE-1164 which addresses improper synchronization in kernel memory management operations, and represents a critical security flaw that requires immediate remediation in production environments.