Re: [PATCH v3] mm/migrate_device: fix pgtable leak in migrate_vma_insert_huge_pmd_page

[Balbir Singh]

On 5/1/26 22:44, Andrew Morton wrote:
> On Fri,  1 May 2026 17:21:16 +0530 Sunny Patel <nueralspacetech@xxxxxxxxx> wrote:
> 
>> When migrate_vma_insert_huge_pmd_page() jumps to unlock_abort due
>> to a PMD check failure, the pgtable allocated earlier via
>> pte_alloc_one() is never freed, causing a memory leak.
>>
>> Added free_abort label to release the pgtable in error path.
>>
>> ...
>>
>> --- a/mm/migrate_device.c
>> +++ b/mm/migrate_device.c
>> @@ -840,7 +840,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
>>  	} else {
>>  		if (folio_is_zone_device(folio) &&
>>  		    !folio_is_device_coherent(folio)) {
>> -			goto abort;
>> +			goto free_abort;
>>  		}
>>  		entry = folio_mk_pmd(folio, vma->vm_page_prot);
>>  		if (vma->vm_flags & VM_WRITE)
>> @@ -893,6 +893,8 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
>>  
>>  unlock_abort:
>>  	spin_unlock(ptl);
>> +free_abort:
>> +	pte_free(vma->vm_mm, pgtable);
>>  abort:
>>  	for (i = 0; i < HPAGE_PMD_NR; i++)
>>  		src[i] &= ~MIGRATE_PFN_MIGRATE;
> 
> Yikes, we leak that page on several error paths.
> 
> Thanks, I'll retain David's ack from the v2 patch.
> 
> Balbir, please review?


The issue can be reached if we try to migrate a non private/coherent folio (I assume DAX/P2PDMA)
pages. Even migrate_vma_insert_page() has a similar pattern. Creating the pud/pmd/pte structure
there is unnecessary (but not allocations occur, depends on pmd_none() for example), do we want
to clean up all of it (need to think through)?

I'll re-review and send fixes as needed. Looks like David sent some fixes out, will review
those as well.

Balbir