CVE-2022-50849

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP<br /> <br /> An oops can be induced by running &amp;#39;cat /proc/kcore &gt; /dev/null&amp;#39; on<br /> devices using pstore with the ram backend because kmap_atomic() assumes<br /> lowmem pages are accessible with __va().<br /> <br /> Unable to handle kernel paging request at virtual address ffffff807ff2b000<br /> Mem abort info:<br /> ESR = 0x96000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000006<br /> CM = 0, WnR = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000<br /> [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000<br /> Internal error: Oops: 96000006 [#1] PREEMPT SMP<br /> Modules linked in: dm_integrity<br /> CPU: 7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba<br /> Hardware name: Google Lazor (rev3 - 8) (DT)<br /> pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __memcpy+0x110/0x260<br /> lr : vread+0x194/0x294<br /> sp : ffffffc013ee39d0<br /> x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000<br /> x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000<br /> x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21: ffffffc0085a2000<br /> x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60<br /> x14: ffffffffad588000 x13: 0000000000000000 x12: 0000000000000001<br /> x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b<br /> x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 : ffffffc013ee3a78<br /> x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000<br /> Call trace:<br /> __memcpy+0x110/0x260<br /> read_kcore+0x584/0x778<br /> proc_reg_read+0xb4/0xe4<br /> <br /> During early boot, memblock reserves the pages for the ramoops reserved<br /> memory node in DT that would otherwise be part of the direct lowmem<br /> mapping. Pstore&amp;#39;s ram backend reuses those reserved pages to change the<br /> memory type (writeback or non-cached) by passing the pages to vmap()<br /> (see pfn_to_page() usage in persistent_ram_vmap() for more details) with<br /> specific flags. When read_kcore() starts iterating over the vmalloc<br /> region, it runs over the virtual address that vmap() returned for<br /> ramoops. In aligned_vread() the virtual address is passed to<br /> vmalloc_to_page() which returns the page struct for the reserved lowmem<br /> area. That lowmem page is passed to kmap_atomic(), which effectively<br /> calls page_to_virt() that assumes a lowmem page struct must be directly<br /> accessible with __va() and friends. These pages are mapped via vmap()<br /> though, and the lowmem mapping was never made, so accessing them via the<br /> lowmem virtual address oopses like above.<br /> <br /> Let&amp;#39;s side-step this problem by passing VM_IOREMAP to vmap(). This will<br /> tell vread() to not include the ramoops region in the kcore. Instead the<br /> area will look like a bunch of zeros. The alternative is to teach kmap()<br /> about vmalloc areas that intersect with lowmem. Presumably such a change<br /> isn&amp;#39;t a one-liner, and there isn&amp;#39;t much interest in inspecting the<br /> ramoops region in kcore files anyway, so the most expedient route is<br /> taken for now.