| From bippy-1.1.0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@kernel.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2022-49851: riscv: fix reserved memory setup |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| riscv: fix reserved memory setup |
| |
| Currently, RISC-V sets up reserved memory using the "early" copy of the |
| device tree. As a result, when trying to get a reserved memory region |
| using of_reserved_mem_lookup(), the pointer to reserved memory regions |
| is using the early, pre-virtual-memory address which causes a kernel |
| panic when trying to use the buffer's name: |
| |
| Unable to handle kernel paging request at virtual address 00000000401c31ac |
| Oops [#1] |
| Modules linked in: |
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1 |
| Hardware name: Microchip PolarFire-SoC Icicle Kit (DT) |
| epc : string+0x4a/0xea |
| ra : vsnprintf+0x1e4/0x336 |
| epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0 |
| gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000 |
| t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20 |
| s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000 |
| a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff |
| a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff |
| s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008 |
| s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00 |
| s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002 |
| s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617 |
| t5 : ffffffff812f3618 t6 : ffffffff81203d08 |
| status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d |
| [<ffffffff80338936>] vsnprintf+0x1e4/0x336 |
| [<ffffffff80055ae2>] vprintk_store+0xf6/0x344 |
| [<ffffffff80055d86>] vprintk_emit+0x56/0x192 |
| [<ffffffff80055ed8>] vprintk_default+0x16/0x1e |
| [<ffffffff800563d2>] vprintk+0x72/0x80 |
| [<ffffffff806813b2>] _printk+0x36/0x50 |
| [<ffffffff8068af48>] print_reserved_mem+0x1c/0x24 |
| [<ffffffff808057ec>] paging_init+0x528/0x5bc |
| [<ffffffff808031ae>] setup_arch+0xd0/0x592 |
| [<ffffffff8080070e>] start_kernel+0x82/0x73c |
| |
| early_init_fdt_scan_reserved_mem() takes no arguments as it operates on |
| initial_boot_params, which is populated by early_init_dt_verify(). On |
| RISC-V, early_init_dt_verify() is called twice. Once, directly, in |
| setup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly, |
| very early in the boot process, by parse_dtb() when it calls |
| early_init_dt_scan_nodes(). |
| |
| This first call uses dtb_early_va to set initial_boot_params, which is |
| not usable later in the boot process when |
| early_init_fdt_scan_reserved_mem() is called. On arm64 for example, the |
| corresponding call to early_init_dt_scan_nodes() uses fixmap addresses |
| and doesn't suffer the same fate. |
| |
| Move early_init_fdt_scan_reserved_mem() further along the boot sequence, |
| after the direct call to early_init_dt_verify() in setup_arch() so that |
| the names use the correct virtual memory addresses. The above supposed |
| that CONFIG_BUILTIN_DTB was not set, but should work equally in the case |
| where it is - unflatted_and_copy_device_tree() also updates |
| initial_boot_params. |
| |
| The Linux kernel CVE team has assigned CVE-2022-49851 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 5.4 with commit 922b0375fc93fb1a20c5617e37c389c26bbccb70 and fixed in 5.10.155 with commit 94ab8f88feb75e3b1486102c0c9c550f37d9d137 |
| Issue introduced in 5.4 with commit 922b0375fc93fb1a20c5617e37c389c26bbccb70 and fixed in 5.15.79 with commit 518e49f0590de66555503aabe199ba8d3f2e24ac |
| Issue introduced in 5.4 with commit 922b0375fc93fb1a20c5617e37c389c26bbccb70 and fixed in 6.0.9 with commit 93598deb101540c4f9e7de15099ea8255b965fc2 |
| Issue introduced in 5.4 with commit 922b0375fc93fb1a20c5617e37c389c26bbccb70 and fixed in 6.1 with commit 50e63dd8ed92045eb70a72d7ec725488320fb68b |
| Issue introduced in 5.3.8 with commit f18ed5bee7bb8a0e99e1c7e7d45e0e51d3497248 |
| |
| 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-49851 |
| 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: |
| arch/riscv/kernel/setup.c |
| arch/riscv/mm/init.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/94ab8f88feb75e3b1486102c0c9c550f37d9d137 |
| https://git.kernel.org/stable/c/518e49f0590de66555503aabe199ba8d3f2e24ac |
| https://git.kernel.org/stable/c/93598deb101540c4f9e7de15099ea8255b965fc2 |
| https://git.kernel.org/stable/c/50e63dd8ed92045eb70a72d7ec725488320fb68b |
