All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Mike Rapoport <rppt@kernel.org>
Cc: Google Big Sleep <big-sleep-vuln-reports@google.com>,
	David Hildenbrand <david@redhat.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH 6.1.y] mm/secretmem: fix use-after-free race in fault handler
Date: Fri, 21 Nov 2025 10:52:11 +0800	[thread overview]
Message-ID: <e9cab398-5d55-45fb-b155-50919546300c@linux.dev> (raw)
In-Reply-To: <aR9vzeI5Tso6g7PO@kernel.org>

Hi Mike,

Thanks for taking care of the backport conflicts, much appreciated! That
saved me a lot of work/time!

Cheers,
Lance

On 2025/11/21 03:45, Mike Rapoport wrote:
> Oops, copied the wrong git send-email command, sorry for the noise
> 
> On Thu, Nov 20, 2025 at 09:15:47PM +0200, Mike Rapoport wrote:
>> From: Lance Yang <lance.yang@linux.dev>
>>
>> When a page fault occurs in a secret memory file created with
>> `memfd_secret(2)`, the kernel will allocate a new page for it, mark the
>> underlying page as not-present in the direct map, and add it to the file
>> mapping.
>>
>> If two tasks cause a fault in the same page concurrently, both could end
>> up allocating a page and removing the page from the direct map, but only
>> one would succeed in adding the page to the file mapping.  The task that
>> failed undoes the effects of its attempt by (a) freeing the page again
>> and (b) putting the page back into the direct map.  However, by doing
>> these two operations in this order, the page becomes available to the
>> allocator again before it is placed back in the direct mapping.
>>
>> If another task attempts to allocate the page between (a) and (b), and the
>> kernel tries to access it via the direct map, it would result in a
>> supervisor not-present page fault.
>>
>> Fix the ordering to restore the direct map before the page is freed.
>>
>> Link: https://lkml.kernel.org/r/20251031120955.92116-1-lance.yang@linux.dev
>> Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas")
>> Signed-off-by: Lance Yang <lance.yang@linux.dev>
>> Reported-by: Google Big Sleep <big-sleep-vuln-reports@google.com>
>> Closes: https://lore.kernel.org/linux-mm/CAEXGt5QeDpiHTu3K9tvjUTPqo+d-=wuCNYPa+6sWKrdQJ-ATdg@mail.gmail.com/
>> Acked-by: David Hildenbrand <david@redhat.com>
>> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> (cherry picked from commit 6f86d0534fddfbd08687fa0f01479d4226bc3c3d)
>> [rppt: replaced folio with page in the patch and in the changelog]
>> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>> ---
>>   mm/secretmem.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/secretmem.c b/mm/secretmem.c
>> index 624663a94808..0c86133ad33f 100644
>> --- a/mm/secretmem.c
>> +++ b/mm/secretmem.c
>> @@ -82,13 +82,13 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
>>   		__SetPageUptodate(page);
>>   		err = add_to_page_cache_lru(page, mapping, offset, gfp);
>>   		if (unlikely(err)) {
>> -			put_page(page);
>>   			/*
>>   			 * If a split of large page was required, it
>>   			 * already happened when we marked the page invalid
>>   			 * which guarantees that this call won't fail
>>   			 */
>>   			set_direct_map_default_noflush(page);
>> +			put_page(page);
>>   			if (err == -EEXIST)
>>   				goto retry;
>>   
>> -- 
>> 2.50.1
>>
> 


  reply	other threads:[~2025-11-21  2:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20 16:12 FAILED: patch "[PATCH] mm/mm_init: fix hash table order logging in" failed to apply to 6.1-stable tree gregkh
2025-11-20 19:15 ` [PATCH 6.1.y] mm/secretmem: fix use-after-free race in fault handler Mike Rapoport
2025-11-20 19:45   ` Mike Rapoport
2025-11-21  2:52     ` Lance Yang [this message]
2025-11-26 12:55   ` Sasha Levin
2025-11-20 19:42 ` [PATCH 6.1.y] mm/mm_init: fix hash table order logging in alloc_large_system_hash() Mike Rapoport
2025-11-20 21:15   ` Isaac Manjarres
2025-11-26 13:04   ` Sasha Levin
  -- strict thread matches above, loose matches on Subject: below --
2025-11-20 16:11 FAILED: patch "[PATCH] mm/secretmem: fix use-after-free race in fault handler" failed to apply to 6.1-stable tree gregkh
2025-11-20 19:19 ` [PATCH 6.1.y] mm/secretmem: fix use-after-free race in fault handler Mike Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e9cab398-5d55-45fb-b155-50919546300c@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=big-sleep-vuln-reports@google.com \
    --cc=david@redhat.com \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=rppt@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.