Re: + mm-pgtable-make-ptlock-be-freed-by-rcu.patch added to mm-unstable branch

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

 



On Tue, Dec 10, 2024 at 07:09:31PM -0800, Andrew Morton wrote:
> 
> The patch titled
>      Subject: mm: pgtable: make ptlock be freed by RCU
> has been added to the -mm mm-unstable branch.  Its filename is
>      mm-pgtable-make-ptlock-be-freed-by-rcu.patch
> 
> This patch will shortly appear at
>      https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-pgtable-make-ptlock-be-freed-by-rcu.patch
> 
> This patch will later appear in the mm-unstable branch at
>     git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> 
> Before you just go and hit "reply", please:
>    a) Consider who else should be cc'ed
>    b) Prefer to cc a suitable mailing list as well
>    c) Ideally: find the original patch on the mailing list and do a
>       reply-to-all to that, adding suitable additional cc's
> 
> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
> 
> The -mm tree is included into linux-next via the mm-everything
> branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> and is updated there every 2-3 working days
> 
> ------------------------------------------------------
> From: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> Subject: mm: pgtable: make ptlock be freed by RCU
> Date: Tue, 10 Dec 2024 16:44:31 +0800
> 
> If ALLOC_SPLIT_PTLOCKS is enabled, the ptdesc->ptl will be a pointer and a
> ptlock will be allocated for it, and it will be freed immediately before
> the PTE page is freed.  Once we support empty PTE page reclaimation, it
> may result in the following use-after-free problem:
> 
> 	CPU 0				CPU 1
> 
> 					pte_offset_map_rw_nolock(&ptlock)
> 					--> rcu_read_lock()
> 	madvise(MADV_DONTNEED)
> 	--> ptlock_free (free ptlock immediately!)
> 	    free PTE page via RCU
> 					/* UAF!! */
> 					spin_lock(ptlock)
> 
> To avoid this problem, make ptlock also be freed by RCU.
> 
> Link: https://lkml.kernel.org/r/20241210084431.91414-1-zhengqi.arch@xxxxxxxxxxxxx
> Signed-off-by: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>

UURGGH... why can't we move the freeing of the lock into
__tlb_remove_table() ?




[Index of Archives]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux