[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2fda0d01-e86a-41ce-95ff-4d24cf3cca32@redhat.com>
Date: Tue, 13 Aug 2024 11:28:29 +0200
From: David Hildenbrand <david@...hat.com>
To: Jann Horn <jannh@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>,
Pavel Emelyanov <xemul@...allels.com>, Andrea Arcangeli
<aarcange@...hat.com>, Hugh Dickins <hughd@...gle.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 1/2] userfaultfd: Fix pmd_trans_huge() recheck race
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@...r.kernel.org
> Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation")
> Signed-off-by: Jann Horn <jannh@...gle.com>
> ---
Acked-by: David Hildenbrand <david@...hat.com>
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists