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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux