[PATCH 1/2] mm/memfd_luo: reject memfds whose page count exceeds UINT_MAX

[PATCH 1/2] mm/memfd_luo: reject memfds whose page count exceeds UINT_MAX

[David Carlier]

memfd_luo_preserve_folios() declares max_folios as unsigned int and
computes it from the inode size, then passes it to memfd_pin_folios()
which itself caps max_folios at unsigned int.  For files whose base-page
count exceeds UINT_MAX (larger than 16 TiB with 4 KiB pages), the
assignment truncates silently: only a prefix of the file gets pinned and
preserved, while memfd_luo_preserve() still records the full inode size
in ser->size.  On retrieve the inode is restored to the full size but
only the preserved prefix repopulates the page cache, so the tail comes
back as holes and user data is silently lost across the live update.

Reject such files at preserve time with -EFBIG rather than chunk the
pin loop, which would also require enlarging the preserved folios array
well beyond what is practical.

Fixes: b3749f174d68 ("mm: memfd_luo: allow preserving memfd")
Signed-off-by: David Carlier <devnexen@gmail.com>
---
 mm/memfd_luo.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
index b02b503c750d..f41d11053b7d 100644
--- a/mm/memfd_luo.c
+++ b/mm/memfd_luo.c
@@ -259,7 +259,7 @@ static int memfd_luo_preserve(struct liveupdate_file_op_args *args)
 	struct inode *inode = file_inode(args->file);
 	struct memfd_luo_folio_ser *folios_ser;
 	struct memfd_luo_ser *ser;
-	u64 nr_folios;
+	u64 nr_folios, inode_size;
 	int err = 0, seals;
 
 	inode_lock(inode);
@@ -285,7 +285,18 @@ static int memfd_luo_preserve(struct liveupdate_file_op_args *args)
 	}
 
 	ser->pos = args->file->f_pos;
-	ser->size = i_size_read(inode);
+	inode_size = i_size_read(inode);
+
+	/*
+	 * memfd_pin_folios() caps at UINT_MAX folios; refuse larger
+	 * files to avoid silently preserving only a prefix.
+	 */
+	if (DIV_ROUND_UP_ULL(inode_size, PAGE_SIZE) > UINT_MAX) {
+		err = -EFBIG;
+		goto err_free_ser;
+	}
+
+	ser->size = inode_size;
 	ser->seals = seals;
 
 	err = memfd_luo_preserve_folios(args->file, &ser->folios,
-- 
2.53.0

[PATCH 2/2] mm/memfd_luo: document preservation of file seals

[David Carlier]

Commit 8a552d68a86e ("mm: memfd_luo: preserve file seals") started
preserving file seals across live update and restoring them via
memfd_add_seals() on retrieve, but the DOC header was not updated and
still listed seals under "Non-Preserved Properties" as being unsealed
on restore.

Move the Seals entry to the "Preserved Properties" section and describe
the actual behavior, including the MEMFD_LUO_ALL_SEALS restriction that
both preserve and retrieve enforce.

Fixes: 8a552d68a86e ("mm: memfd_luo: preserve file seals")
Signed-off-by: David Carlier <devnexen@gmail.com>
---
 mm/memfd_luo.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
index f41d11053b7d..c5250f68c096 100644
--- a/mm/memfd_luo.c
+++ b/mm/memfd_luo.c
@@ -50,6 +50,11 @@
  *   memfds are always opened with ``O_RDWR`` and ``O_LARGEFILE``. This property
  *   is maintained.
  *
+ * Seals
+ *   File seals set on the memfd are preserved and re-applied on restore.
+ *   Only seals known to this LUO version (see ``MEMFD_LUO_ALL_SEALS``) may
+ *   be present; preservation fails with ``-EOPNOTSUPP`` otherwise.
+ *
  * Non-Preserved Properties
  * ========================
  *
@@ -61,10 +66,6 @@
  *   A memfd can be created with the ``MFD_CLOEXEC`` flag that sets the
  *   ``FD_CLOEXEC`` on the file. This flag is not preserved and must be set
  *   again after restore via ``fcntl()``.
- *
- * Seals
- *   File seals are not preserved. The file is unsealed on restore and if
- *   needed, must be sealed again via ``fcntl()``.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
2.53.0

Re: [PATCH 1/2] mm/memfd_luo: reject memfds whose page count exceeds UINT_MAX

[Pasha Tatashin]

On 04-23 13:56, David Carlier wrote:
> memfd_luo_preserve_folios() declares max_folios as unsigned int and
> computes it from the inode size, then passes it to memfd_pin_folios()
> which itself caps max_folios at unsigned int.  For files whose base-page
> count exceeds UINT_MAX (larger than 16 TiB with 4 KiB pages), the
> assignment truncates silently: only a prefix of the file gets pinned and
> preserved, while memfd_luo_preserve() still records the full inode size
> in ser->size.  On retrieve the inode is restored to the full size but
> only the preserved prefix repopulates the page cache, so the tail comes
> back as holes and user data is silently lost across the live update.
> 
> Reject such files at preserve time with -EFBIG rather than chunk the
> pin loop, which would also require enlarging the preserved folios array
> well beyond what is practical.
> 
> Fixes: b3749f174d68 ("mm: memfd_luo: allow preserving memfd")
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
>  mm/memfd_luo.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/memfd_luo.c b/mm/memfd_luo.c
> index b02b503c750d..f41d11053b7d 100644
> --- a/mm/memfd_luo.c
> +++ b/mm/memfd_luo.c
> @@ -259,7 +259,7 @@ static int memfd_luo_preserve(struct liveupdate_file_op_args *args)
>  	struct inode *inode = file_inode(args->file);
>  	struct memfd_luo_folio_ser *folios_ser;
>  	struct memfd_luo_ser *ser;
> -	u64 nr_folios;
> +	u64 nr_folios, inode_size;
>  	int err = 0, seals;
>  
>  	inode_lock(inode);
> @@ -285,7 +285,18 @@ static int memfd_luo_preserve(struct liveupdate_file_op_args *args)
>  	}
>  
>  	ser->pos = args->file->f_pos;
> -	ser->size = i_size_read(inode);
> +	inode_size = i_size_read(inode);
> +
> +	/*
> +	 * memfd_pin_folios() caps at UINT_MAX folios; refuse larger
> +	 * files to avoid silently preserving only a prefix.
> +	 */

I think, the fix should be first done at memfd_pin_folios() to change 
max_folios to 'long' or 'unsigned long', and then just updated 
memfd_luo.c to match.

Pasha

> +	if (DIV_ROUND_UP_ULL(inode_size, PAGE_SIZE) > UINT_MAX) {
> +		err = -EFBIG;
> +		goto err_free_ser;
> +	}
> +
> +	ser->size = inode_size;
>  	ser->seals = seals;
>  
>  	err = memfd_luo_preserve_folios(args->file, &ser->folios,
> -- 
> 2.53.0
> 

Re: [PATCH 1/2] mm/memfd_luo: reject memfds whose page count exceeds UINT_MAX

[David CARLIER]

On 2026-05-01 18:59, Pasha Tatashin wrote:
  > I think, the fix should be first done at memfd_pin_folios() to
change
  > max_folios to 'long' or 'unsigned long', and then just updated
  > memfd_luo.c to match.

  Even with memfd_pin_folios() widened, memfd_luo_preserve_folios()
still
  kvmalloc_objs()s the folios array up front -- at UINT_MAX entries
that's
  already ~32 GiB of pointer array, which won't realistically succeed.
So
  the guard here still makes sense, just on allocation grounds rather than
  interface truncation.

  Happy to widen memfd_pin_folios() as a separate patch, but I'd keep
the
  -EFBIG check regardless. Or did you have a different shape in mind?

Cheers.

Re: [PATCH 1/2] mm/memfd_luo: reject memfds whose page count exceeds UINT_MAX

[Pasha Tatashin]

On 05-01 20:26, David CARLIER wrote:
> On 2026-05-01 18:59, Pasha Tatashin wrote:
>   > I think, the fix should be first done at memfd_pin_folios() to
> change
>   > max_folios to 'long' or 'unsigned long', and then just updated
>   > memfd_luo.c to match.
> 
>   Even with memfd_pin_folios() widened, memfd_luo_preserve_folios()
> still
>   kvmalloc_objs()s the folios array up front -- at UINT_MAX entries
> that's
>   already ~32 GiB of pointer array, which won't realistically succeed.
> So
>   the guard here still makes sense, just on allocation grounds rather than
>   interface truncation.
> 
>   Happy to widen memfd_pin_folios() as a separate patch, but I'd keep
> the
>   -EFBIG check regardless. Or did you have a different shape in mind?

Ah, Good point about kvmalloc_objs(), I am not against this, even though 
it is a very theoretical issue.

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> 

Re: [PATCH 2/2] mm/memfd_luo: document preservation of file seals

[Pasha Tatashin]

On 04-23 13:56, David Carlier wrote:
> Commit 8a552d68a86e ("mm: memfd_luo: preserve file seals") started
> preserving file seals across live update and restoring them via
> memfd_add_seals() on retrieve, but the DOC header was not updated and
> still listed seals under "Non-Preserved Properties" as being unsealed
> on restore.
> 
> Move the Seals entry to the "Preserved Properties" section and describe
> the actual behavior, including the MEMFD_LUO_ALL_SEALS restriction that
> both preserve and retrieve enforce.
> 
> Fixes: 8a552d68a86e ("mm: memfd_luo: preserve file seals")
> Signed-off-by: David Carlier <devnexen@gmail.com>

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> 

Re: [PATCH 1/2] mm/memfd_luo: reject memfds whose page count exceeds UINT_MAX

[Pratyush Yadav]

On Fri, May 01 2026, Pasha Tatashin wrote:

> On 05-01 20:26, David CARLIER wrote:
>> On 2026-05-01 18:59, Pasha Tatashin wrote:
>>   > I think, the fix should be first done at memfd_pin_folios() to
>> change
>>   > max_folios to 'long' or 'unsigned long', and then just updated
>>   > memfd_luo.c to match.
>> 
>>   Even with memfd_pin_folios() widened, memfd_luo_preserve_folios()
>> still
>>   kvmalloc_objs()s the folios array up front -- at UINT_MAX entries
>> that's
>>   already ~32 GiB of pointer array, which won't realistically succeed.
>> So
>>   the guard here still makes sense, just on allocation grounds rather than
>>   interface truncation.
>> 
>>   Happy to widen memfd_pin_folios() as a separate patch, but I'd keep
>> the
>>   -EFBIG check regardless. Or did you have a different shape in mind?
>
> Ah, Good point about kvmalloc_objs(), I am not against this, even though 
> it is a very theoretical issue.

Yeah. I plan to get rid of the pinning anyway and do this via the page
cache directly (might be easier said than done though), so this should
be fine for now I think. I suspect we might run into a lot more problems
if we get a memfd like this anyway.

Reviewed-by: Pratyush Yadav <pratyush@kernel.org>

>
> Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> 

-- 
Regards,
Pratyush Yadav

Re: [PATCH 2/2] mm/memfd_luo: document preservation of file seals

[Pratyush Yadav]

On Thu, Apr 23 2026, David Carlier wrote:

> Commit 8a552d68a86e ("mm: memfd_luo: preserve file seals") started
> preserving file seals across live update and restoring them via
> memfd_add_seals() on retrieve, but the DOC header was not updated and
> still listed seals under "Non-Preserved Properties" as being unsealed
> on restore.
>
> Move the Seals entry to the "Preserved Properties" section and describe
> the actual behavior, including the MEMFD_LUO_ALL_SEALS restriction that
> both preserve and retrieve enforce.
>
> Fixes: 8a552d68a86e ("mm: memfd_luo: preserve file seals")
> Signed-off-by: David Carlier <devnexen@gmail.com>

Thanks for the fix!

Reviewed-by: Pratyush Yadav <pratyush@kernel.org>

[...]

-- 
Regards,
Pratyush Yadav