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@xxxxxxxxxx > > Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") > > Signed-off-by: David Hildenbrand <david@xxxxxxxxxx> > > Reported-by: xingwei lee <xrivendell7@xxxxxxxxx> > > Reported-by: yue sun <samsun1006219@xxxxxxxxx> > > Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2rmz0HQ@xxxxxxxxxxxxxx/ > > Debugged-by: Miklos Szeredi <miklos@xxxxxxxxxx> > > Tested-by: Miklos Szeredi <mszeredi@xxxxxxxxxx> > > Reviewed-by: Mike Rapoport (IBM) <rppt@xxxxxxxxxx> > > Cc: Lorenzo Stoakes <lstoakes@xxxxxxxxx> > > Cc: <stable@xxxxxxxxxxxxxxx> > > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > > (cherry picked from commit 65291dcfcf8936e1b23cfd7718fdfde7cfaf7706) > > Forgot to add when cherry-picking > > Signed-off-by: David Hildenbrand <david@xxxxxxxxxx> Now queued up, thanks. greg k-h
