Re: [PATCH] mm/hugetlb: fix null ptr defer in hugetlb_vma_lock_write

Mike Kravetz
2023-11-03T02:28:43Z

On 11/02/23 19:24, Mike Kravetz wrote:
> On 11/02/23 20:58, Edward Adam Davis wrote:
> > When obtaining resv_map from vma, it is necessary to simultaneously determine
> > the flag HPAGE_RESV_OWNER of vm_private_data.
> > Only when they are met simultaneously, resv_map is valid.
>
> Thanks for looking into this!
>
> The check for HPAGE_RESV_OWNER does 'work'. However, I believe root
> cause is this block of code in __unmap_hugepage_range().
>
> /*
> * If a reference page is supplied, it is because a specific
> * page is being unmapped, not a range. Ensure the page we
> * are about to unmap is the actual page of interest.
> */
> if (ref_page) {
> if (page != ref_page) {
> spin_unlock(ptl);
> continue;
> }
> /*
> * Mark the VMA as having unmapped its page so that
> * future faults in this VMA will fail rather than
> * looking like data was lost
> */
> set_vma_resv_flags(vma, HPAGE_RESV_UNMAPPED);
> }
>
> In the specific case causing the null-ptr-deref, the resv_map pointer
> (vm_private_data) is NULL. So, set_vma_resv_flags() just sets the lower bit.
> Because of this, __vma_private_lock returns true.

Ah!

I see Yin, Fengwei already discovered this code path.

--
Mike Kravetz