| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2025123044-CVE-2022-50849-9dea@gregkh> Date: Tue, 30 Dec 2025 13:19:45 +0100 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-cve-announce@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...nel.org> Subject: CVE-2022-50849: pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP From: Greg Kroah-Hartman <gregkh@...nel.org> Description =========== 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 Linux kernel CVE team has assigned CVE-2022-50849 to this issue. Affected and fixed versions =========================== Issue introduced in 3.4 with commit 404a6043385de17273624b076599669db5ad891f and fixed in 4.9.337 with commit 1579bed1613802a323a1e14567faa95c149e105e Issue introduced in 3.4 with commit 404a6043385de17273624b076599669db5ad891f and fixed in 4.14.303 with commit fdebcc33b663d2e8da937653ddfbfc1315047eaa Issue introduced in 3.4 with commit 404a6043385de17273624b076599669db5ad891f and fixed in 4.19.270 with commit 6d9460214e363e1f3d0756ee5d947e76e3e6f86c Issue introduced in 3.4 with commit 404a6043385de17273624b076599669db5ad891f and fixed in 5.4.229 with commit 4d3126f242a0090342ffe925c35fb4f4252b7562 Issue introduced in 3.4 with commit 404a6043385de17273624b076599669db5ad891f and fixed in 5.10.163 with commit 295f59cd2cdeed841850d02dddde3a122cbf6fc6 Issue introduced in 3.4 with commit 404a6043385de17273624b076599669db5ad891f and fixed in 5.15.86 with commit ebc73c4f266281e2cad1a372ecd81572d95375b6 Issue introduced in 3.4 with commit 404a6043385de17273624b076599669db5ad891f and fixed in 6.0.16 with commit 69dbff7d2681c55a4d979fd9b75576303e69979f Issue introduced in 3.4 with commit 404a6043385de17273624b076599669db5ad891f and fixed in 6.1.2 with commit 2f82381d0681b10f9ddd27be98c27363b5a3cd1c Issue introduced in 3.4 with commit 404a6043385de17273624b076599669db5ad891f and fixed in 6.2 with commit e6b842741b4f39007215fd7e545cb55aa3d358a2 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2022-50849 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: fs/pstore/ram_core.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/1579bed1613802a323a1e14567faa95c149e105e https://git.kernel.org/stable/c/fdebcc33b663d2e8da937653ddfbfc1315047eaa https://git.kernel.org/stable/c/6d9460214e363e1f3d0756ee5d947e76e3e6f86c https://git.kernel.org/stable/c/4d3126f242a0090342ffe925c35fb4f4252b7562 https://git.kernel.org/stable/c/295f59cd2cdeed841850d02dddde3a122cbf6fc6 https://git.kernel.org/stable/c/ebc73c4f266281e2cad1a372ecd81572d95375b6 https://git.kernel.org/stable/c/69dbff7d2681c55a4d979fd9b75576303e69979f https://git.kernel.org/stable/c/2f82381d0681b10f9ddd27be98c27363b5a3cd1c https://git.kernel.org/stable/c/e6b842741b4f39007215fd7e545cb55aa3d358a2
Powered by blists - more mailing lists