On 04.07.24 20:40, Andrew Morton wrote:
On Tue, 25 Jun 2024 14:06:43 -0700 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
On Wed, 13 Mar 2024 09:29:13 +0800 Peng Zhang <zhangpeng362@xxxxxxxxxx> wrote:
From: ZhangPeng <zhangpeng362@xxxxxxxxxx>
The vmf->ptl in filemap_fault_recheck_pte_none() is still set from
handle_pte_fault(). But at the same time, we did a pte_unmap(vmf->pte).
After a pte_unmap(vmf->pte) unmap and rcu_read_unlock(), the page table
may be racily changed and vmf->ptl maybe fails to protect the actual
page table.
Fix this by replacing pte_offset_map() with pte_offset_map_nolock().
...
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3207,7 +3207,8 @@ static vm_fault_t filemap_fault_recheck_pte_none(struct vm_fault *vmf)
if (!(vmf->flags & FAULT_FLAG_ORIG_PTE_VALID))
return 0;
- ptep = pte_offset_map(vmf->pmd, vmf->address);
+ ptep = pte_offset_map_nolock(vma->vm_mm, vmf->pmd, vmf->address,
+ &vmf->ptl);
if (unlikely(!ptep))
return VM_FAULT_NOPAGE;
whoops, I'm still sitting on this because I didn't know whether we
should backport it.
And... guess what I say next. Can we please describe what are the
userspace visible effects of the bug?
Nobody?
Oh well, I'll add cc:stable amd move this into mm-hotfixes.
Yeah, we should better do that. IIRC, the PTL pointer might be stale
(use after free?), although I cannot judge how often that should
actually happen.
--
Cheers,
David / dhildenb
