Re: [PATCH for 4.14-stable] s390/mm: validate VMA in PGSTE manipulation functions

[David Hildenbrand <david@redhat.com>]

On 28.11.21 12:54, Greg KH wrote:
> On Fri, Nov 26, 2021 at 06:15:36PM +0100, David Hildenbrand wrote:
>> commit fe3d10024073f06f04c74b9674bd71ccc1d787cf upstream.
>>
>> 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 dd2283f2605e ("mm: mmap: zap pages
>> with read mmap_sem in munmap"). gfn_to_hva() will only translate using
>> KVM memory regions, but won't validate the VMA.
>>
>> Further, we should not allocate page tables 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().
>>
>> Fixes: 2d42f9477320 ("s390/kvm: Add PGSTE manipulation functions")
>> 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-4-david@redhat.com
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>>  arch/s390/mm/pgtable.c | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
> 
> What about for 5.10-stable and 5.4-stable and 4.19-stable?  Will this
> commit work there as well?

Good point, I only have "FAILED: patch "[PATCH] s390/mm: validate VMA in
PGSTE manipulation functions" failed to apply to 4.14-stable tree" in my
inbox ... but maybe I accidentally deleted the others.


This commit can also be used for:
- 4.19-stable
- 5.4-stable
- 5.10-stable

They all lack vma_lookup() and we have to implement the start address
check manually.

-- 
Thanks,

David / dhildenb