From e7b28b5bb38ed942bc49b4cf9d313f9a051c9966 Mon Sep 17 00:00:00 2001 From: Mark Johnston Date: Tue, 6 Apr 2021 14:56:37 -0400 Subject: [PATCH] vm_fault: Shoot down multiply mapped COW source page mappings Reviewed by: kib, rlibby Discussed with: alc Approved by: so Security: CVE-2021-29626 Security: FreeBSD-SA-21:08.vm (cherry picked from commit 304a533fd2ec6d61805eb7c991b3e9ce502fc730) --- sys/vm/vm_fault.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index cf2db256eaa..7829b3691d8 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -1298,6 +1298,33 @@ vm_fault(vm_map_t map, vm_offset_t vaddr, vm_prot_t fault_type, vm_page_unwire(fs.m, PQ_INACTIVE); vm_page_unlock(fs.m); } + + /* + * Typically, the shadow object is either + * private to this address space + * (OBJ_ONEMAPPING) or its pages are read only. + * In the highly unusual case where the pages of + * a shadow object are read/write shared between + * this and other address spaces, we need to + * ensure that any pmap-level mappings to the + * original, copy-on-write page from the backing + * object are removed from those other address + * spaces. + * + * The flag check is racy, but this is + * tolerable: if OBJ_ONEMAPPING is cleared after + * the check, the busy state ensures that new + * mappings of fs.m can't be created. + * pmap_enter() will replace an existing mapping + * in the current address space. If + * OBJ_ONEMAPPING is set after the check, + * removing mappings will at worse trigger some + * unnecessary page faults. + */ + vm_page_assert_xbusied(fs.m); + if ((fs.first_object->flags & OBJ_ONEMAPPING) == 0) + pmap_remove_all(fs.m); + /* * We no longer need the old page or object. */ -- 2.45.0