Re: [PATCH 1/2] userfaultfd: Fix pmd_trans_huge() recheck race

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

 



On 12.08.24 18:42, Jann Horn wrote:
The following race can occur:

   mfill_atomic                other thread
   ============                ============
                               <zap PMD>
   pmdp_get_lockless() [reads none pmd]
   <bail if trans_huge>
   <if none:>
                               <pagefault creates transhuge zeropage>
     __pte_alloc [no-op]
                               <zap PMD>
   <bail if pmd_trans_huge(*dst_pmd)>
   BUG_ON(pmd_none(*dst_pmd))

I have experimentally verified this in a kernel with extra mdelay() calls;
the BUG_ON(pmd_none(*dst_pmd)) triggers.

On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow
pte_offset_map[_lock]() to fail"), this can't lead to anything worse than
a BUG_ON(), since the page table access helpers are actually designed to
deal with page tables concurrently disappearing; but on older kernels
(<=6.4), I think we could probably theoretically race past the two BUG_ON()
checks and end up treating a hugepage as a page table.

Cc: stable@xxxxxxxxxxxxxxx
Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation")
Signed-off-by: Jann Horn <jannh@xxxxxxxxxx>
---

Acked-by: David Hildenbrand <david@xxxxxxxxxx>

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux