Re: [PATCH 6.1.y] mm/secretmem: fix GUP-fast succeeding on secretmem folios

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Apr 08, 2024 at 12:39:51PM +0200, David Hildenbrand wrote:
> On 08.04.24 12:34, David Hildenbrand wrote:
> > folio_is_secretmem() currently relies on secretmem folios being LRU
> > folios, to save some cycles.
> > 
> > However, folios might reside in a folio batch without the LRU flag set, or
> > temporarily have their LRU flag cleared.  Consequently, the LRU flag is
> > unreliable for this purpose.
> > 
> > In particular, this is the case when secretmem_fault() allocates a fresh
> > page and calls filemap_add_folio()->folio_add_lru().  The folio might be
> > added to the per-cpu folio batch and won't get the LRU flag set until the
> > batch was drained using e.g., lru_add_drain().
> > 
> > Consequently, folio_is_secretmem() might not detect secretmem folios and
> > GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel
> > when we would later try reading/writing to the folio, because the folio
> > has been unmapped from the directmap.
> > 
> > Fix it by removing that unreliable check.
> > 
> > Link: https://lkml.kernel.org/r/20240326143210.291116-2-david@redhat.com
> > Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas")
> > Signed-off-by: David Hildenbrand <david@redhat.com>
> > Reported-by: xingwei lee <xrivendell7@gmail.com>
> > Reported-by: yue sun <samsun1006219@gmail.com>
> > Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2rmz0HQ@mail.gmail.com/
> > Debugged-by: Miklos Szeredi <miklos@szeredi.hu>
> > Tested-by: Miklos Szeredi <mszeredi@redhat.com>
> > Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > Cc: Lorenzo Stoakes <lstoakes@gmail.com>
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > (cherry picked from commit 65291dcfcf8936e1b23cfd7718fdfde7cfaf7706)
> 
> Forgot to add when cherry-picking
> 
> Signed-off-by: David Hildenbrand <david@redhat.com>

Now queued up, thanks.

greg k-h