Re: [PATCH] fs/ext4: Initialize new folios before use

[Baokun Li]

Hi Bartlomiej,

On 2025-12-24 05:58, Bartlomiej Kubik wrote:
> KMSAN reports an uninitialized value in adiantum_crypt, created at
> write_begin_get_folio(). New folios are allocated with the FGP_CREAT
> flag and may be returned uninitialized. These uninitialized folios are
> then used without proper initialization.
>
> Fixes: b799474b9aeb ("mm/pagemap: add write_begin_get_folio() helper function")
> Tested-by: syzbot+703d8a2cd20971854b06@xxxxxxxxxxxxxxxxxxxxxxxxx
> Reported-by: syzbot+703d8a2cd20971854b06@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://syzkaller.appspot.com/bug?extid=703d8a2cd20971854b06
>
> Signed-off-by: Bartlomiej Kubik <kubik.bartlomiej@xxxxxxxxx>
> ---
>  include/linux/pagemap.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index 31a848485ad9..31bbc8299e08 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
> @@ -787,7 +787,8 @@ static inline struct folio *write_begin_get_folio(const struct kiocb *iocb,
>                  fgp_flags |= FGP_DONTCACHE;
>
>          return __filemap_get_folio(mapping, index, fgp_flags,
> -                                   mapping_gfp_mask(mapping));
> +				mapping_gfp_mask(mapping)|
> +				__GFP_ZERO);
We do need to perform some initialization, but doing it in this common
path is clearly unreasonable. It would introduce unnecessary zeroing
overhead even for non-crypto scenarios.

Therefore, I suspect something was missed in certain crypto-related
initialization paths where the zeroing should have been handled instead.


Cheers,
Baokun