Re: [PATCH] mm: fix NULL pointer dereference in wp_page_reuse()

[David Hildenbrand]

On 26.07.22 08:24, Qi Zheng wrote:
> The vmf->page can be NULL when the wp_page_reuse() is invoked
> by wp_pfn_shared(), it will cause the following panic:
> 
> [   12.981200] BUG: kernel NULL pointer dereference, address: 000000000000008
> [   12.981954] #PF: supervisor read access in kernel mode
> [   12.982615] #PF: error_code(0x0000) - not-present page
> [   12.983146] PGD 0 P4D 0
> [   12.983417] Oops: 0000 [#1] PREEMPT SMP PTI
> [   12.983846] CPU: 18 PID: 923 Comm: Xorg Not tainted 5.19.0-rc8.bm.1-amd64 #263
> [   12.984606] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g14
> [   12.985760] RIP: 0010:_compound_head+0x0/0x40
> [...]
> [   12.995932] Call Trace:
> [   12.996199]  <TASK>
> [   12.996424]  wp_page_reuse+0x1c/0xa0
> [   12.996800]  do_wp_page+0x1a5/0x3f0
> [   12.997169]  __handle_mm_fault+0x8cf/0xd20
> [   12.997587]  ? _raw_spin_unlock_irqrestore+0x23/0x35
> [   12.998105]  handle_mm_fault+0xd5/0x2a0
> [   12.998499]  do_user_addr_fault+0x1d0/0x680
> [   12.998930]  exc_page_fault+0x78/0x170
> [   12.999321]  asm_exc_page_fault+0x22/0x30
> 
> To fix it, this patch performs a NULL pointer check before
> dereferencing the vmf->page.
> 
> Fixes: 6c287605fd56 ("mm: remember exclusively mapped anonymous pages with PG_anon_exclusive")
> Signed-off-by: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> ---
>  mm/memory.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index 4cf7d4b6c950..9174918ce3f7 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3043,7 +3043,7 @@ static inline void wp_page_reuse(struct vm_fault *vmf)
>  	pte_t entry;
>  
>  	VM_BUG_ON(!(vmf->flags & FAULT_FLAG_WRITE));
> -	VM_BUG_ON(PageAnon(page) && !PageAnonExclusive(page));
> +	VM_BUG_ON(page && PageAnon(page) && !PageAnonExclusive(page));
>  
>  	/*
>  	 * Clear the pages cpupid information as the existing

Indeed, fortunately, only an issue in the VM_BUG_ON statement

Reviewed-by: David Hildenbrand <david@xxxxxxxxxx>

-- 
Thanks,

David / dhildenb