CVE-2021-47531

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP<br /> <br /> In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object<br /> function") we switched to a new/cleaner method of doing things. That&amp;#39;s<br /> good, but we missed a little bit.<br /> <br /> Before that commit, we used to _first_ run through the<br /> drm_gem_mmap_obj() case where `obj-&gt;funcs-&gt;mmap()` was NULL. That meant<br /> that we ran:<br /> <br /> vma-&gt;vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;<br /> vma-&gt;vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma-&gt;vm_flags));<br /> vma-&gt;vm_page_prot = pgprot_decrypted(vma-&gt;vm_page_prot);<br /> <br /> ...and _then_ we modified those mappings with our own. Now that<br /> `obj-&gt;funcs-&gt;mmap()` is no longer NULL we don&amp;#39;t run the default<br /> code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP<br /> was important because we&amp;#39;re now getting crashes on Chromebooks that<br /> use ARC++ while logging out. Specifically a crash that looks like this<br /> (this is on a 5.10 kernel w/ relevant backports but also seen on a<br /> 5.15 kernel):<br /> <br /> Unable to handle kernel paging request at virtual address ffffffc008000000<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 /> Data abort info:<br /> ISV = 0, ISS = 0x00000006<br /> CM = 0, WnR = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008293d000<br /> [ffffffc008000000] pgd=00000001002b3003, p4d=00000001002b3003,<br /> pud=00000001002b3003, pmd=0000000000000000<br /> Internal error: Oops: 96000006 [#1] PREEMPT SMP<br /> [...]<br /> CPU: 7 PID: 15734 Comm: crash_dump64 Tainted: G W 5.10.67 #1 [...]<br /> Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT)<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)<br /> pc : __arch_copy_to_user+0xc0/0x30c<br /> lr : copyout+0xac/0x14c<br /> [...]<br /> Call trace:<br /> __arch_copy_to_user+0xc0/0x30c<br /> copy_page_to_iter+0x1a0/0x294<br /> process_vm_rw_core+0x240/0x408<br /> process_vm_rw+0x110/0x16c<br /> __arm64_sys_process_vm_readv+0x30/0x3c<br /> el0_svc_common+0xf8/0x250<br /> do_el0_svc+0x30/0x80<br /> el0_svc+0x10/0x1c<br /> el0_sync_handler+0x78/0x108<br /> el0_sync+0x184/0x1c0<br /> Code: f8408423 f80008c3 910020c6 36100082 (b8404423)<br /> <br /> Let&amp;#39;s add the two flags back in.<br /> <br /> While we&amp;#39;re at it, the fact that we aren&amp;#39;t running the default means<br /> that we _don&amp;#39;t_ need to clear out VM_PFNMAP, so remove that and save<br /> an instruction.<br /> <br /> NOTE: it was confirmed that VM_IO was the important flag to fix the<br /> problem I was seeing, but adding back VM_DONTDUMP seems like a sane<br /> thing to do so I&amp;#39;m doing that too.