CVE-2022-50849

pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP

published December 30, 2025

CVSS
—
EPSS
0%
Percentile
13.3
In the wild
Unconfirmed
What it is

In the Linux kernel, the following vulnerability has been resolved:

pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP

An oops can be induced by running 'cat /proc/kcore > /dev/null' on

devices using pstore with the ram backend because kmap_atomic() assumes

lowmem pages are accessible with __va().

Unable to handle kernel paging request at virtual address ffffff807ff2b000

Mem abort info:

ESR = 0x96000006

EC = 0x25: DABT (current EL), IL = 32 bits

SET = 0, FnV = 0

EA = 0, S1PTW = 0

FSC = 0x06: level 2 translation fault

Data abort info:

ISV = 0, ISS = 0x00000006

CM = 0, WnR = 0

swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000

[ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000

Internal error: Oops: 96000006 [#1] PREEMPT SMP

Modules linked in: dm_integrity

CPU: 7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba

Hardware name: Google Lazor (rev3 - 8) (DT)

pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)

pc : __memcpy+0x110/0x260

lr : vread+0x194/0x294

sp : ffffffc013ee39d0

x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000

x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000

x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21: ffffffc0085a2000

x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000

x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60

x14: ffffffffad588000 x13: 0000000000000000 x12: 0000000000000001

x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b

x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000

x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 : ffffffc013ee3a78

x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000

Call trace:

__memcpy+0x110/0x260

read_kcore+0x584/0x778

proc_reg_read+0xb4/0xe4

During early boot, memblock reserves the pages for the ramoops reserved

memory node in DT that would otherwise be part of the direct lowmem

mapping. Pstore's ram backend reuses those reserved pages to change the

memory type (writeback or non-cached) by passing the pages to vmap()

(see pfn_to_page() usage in persistent_ram_vmap() for more details) with

specific flags. When read_kcore() starts iterating over the vmalloc

region, it runs over the virtual address that vmap() returned for

ramoops. In aligned_vread() the virtual address is passed to

vmalloc_to_page() which returns the page struct for the reserved lowmem

area. That lowmem page is passed to kmap_atomic(), which effectively

calls page_to_virt() that assumes a lowmem page struct must be directly

accessible with __va() and friends. These pages are mapped via vmap()

though, and the lowmem mapping was never made, so accessing them via the

lowmem virtual address oopses like above.

Let's side-step this problem by passing VM_IOREMAP to vmap(). This will

tell vread() to not include the ramoops region in the kcore. Instead the

area will look like a bunch of zeros. The alternative is to teach kmap()

about vmalloc areas that intersect with lowmem. Presumably such a change

isn't a one-liner, and there isn't much interest in inspecting the

ramoops region in kcore files anyway, so the most expedient route is

taken for now.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00232 · 13.3th percentile
Published
2025-12-30T12:15Z
EPSS history
Timeline
  • 30 DEC 12:15Z
    pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP
    cvelistv5