cbcvebase.
CVE-2021-47034
published 2024-02-28

CVE-2021-47034: 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…

PriorityP415medium4.4CVSS 3.1
AVLACLPRHUINSUCNINAH
EPSS
0.22%
12.7th percentile
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

Affected

17 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 5.10.38-1 (bookworm)linux 5.10.38-1 (bookworm)
linuxlinux——
linuxlinux>= f1cb8f9beba8699dd1b4518418191499e53f7b17 < b3d5d0983388d6c4fb35f7d722556d5595f167a7b3d5d0983388d6c4fb35f7d722556d5595f167a7
linuxlinux>= f1cb8f9beba8699dd1b4518418191499e53f7b17 < 73f9dccb29e4f82574bec2765c0090cdb040430173f9dccb29e4f82574bec2765c0090cdb0404301
linuxlinux>= f1cb8f9beba8699dd1b4518418191499e53f7b17 < 84c0762633f2a7ac8399e6b97d3b9bb8e6e1d50f84c0762633f2a7ac8399e6b97d3b9bb8e6e1d50f
linuxlinux>= f1cb8f9beba8699dd1b4518418191499e53f7b17 < 01ac203e2119d8922126886ddea309fb676f955f01ac203e2119d8922126886ddea309fb676f955f
linuxlinux>= f1cb8f9beba8699dd1b4518418191499e53f7b17 < e40c52ee67b155ad59f59e73ea136d02685f0e0de40c52ee67b155ad59f59e73ea136d02685f0e0d
linuxlinux>= f1cb8f9beba8699dd1b4518418191499e53f7b17 < b8b2f37cf632434456182e9002d63cbc4cccc50cb8b2f37cf632434456182e9002d63cbc4cccc50c
linuxlinux_kernel>= 0 < 5.10.38-15.10.38-1
linuxlinux_kernel>= 0 < 5.10.38-15.10.38-1
linuxlinux_kernel>= 0 < 5.10.38-15.10.38-1
linuxlinux_kernel>= 0 < 5.10.38-15.10.38-1
linuxlinux_kernel>= 4.18 < 4.19.1914.19.191
linuxlinux_kernel>= 4.20 < 5.4.1195.4.119
linuxlinux_kernel>= 5.11 < 5.11.215.11.21
linuxlinux_kernel>= 5.12 < 5.12.45.12.4
linuxlinux_kernel>= 5.5 < 5.10.375.10.37

CVSS provenance

nvdv3.14.4MEDIUMCVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
osv4.4MEDIUM
vendor_debian4.4MEDIUM
vendor_redhat4.4MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.