]> git.baikalelectronics.ru Git - kernel.git/commit
s390/gmap: validate VMA in __gmap_zap()
authorDavid Hildenbrand <david@redhat.com>
Thu, 9 Sep 2021 16:22:40 +0000 (18:22 +0200)
committerChristian Borntraeger <borntraeger@de.ibm.com>
Mon, 25 Oct 2021 07:20:38 +0000 (09:20 +0200)
commitccdef958eb51eb846e0dd7ceb8f9673af20a96c1
tree8ab1a00bbe974b7ba1a4080be14d375c3fbb43f2
parent972a6b106bfdb957ad4749f29291e0fe7e21905b
s390/gmap: validate VMA in __gmap_zap()

We should not walk/touch page tables outside of VMA boundaries when
holding only the mmap sem in read mode. Evil user space can modify the
VMA layout just before this function runs and e.g., trigger races with
page table removal code since commit 5dcd5782f466 ("mm: mmap: zap pages
with read mmap_sem in munmap"). The pure prescence in our guest_to_host
radix tree does not imply that there is a VMA.

Further, we should not allocate page tables (via get_locked_pte()) outside
of VMA boundaries: if evil user space decides to map hugetlbfs to these
ranges, bad things will happen because we suddenly have PTE or PMD page
tables where we shouldn't have them.

Similarly, we have to check if we suddenly find a hugetlbfs VMA, before
calling get_locked_pte().

Note that gmap_discard() is different:
zap_page_range()->unmap_single_vma() makes sure to stay within VMA
boundaries.

Fixes: e1a84098296d ("s390/kvm: support collaborative memory management")
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Link: https://lore.kernel.org/r/20210909162248.14969-2-david@redhat.com
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
arch/s390/mm/gmap.c