include/linux/pagemap.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
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@syzkaller.appspotmail.com
Reported-by: syzbot+703d8a2cd20971854b06@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=703d8a2cd20971854b06
Signed-off-by: Bartlomiej Kubik <kubik.bartlomiej@gmail.com>
---
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);
}
/**
--
2.39.5
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@syzkaller.appspotmail.com
> Reported-by: syzbot+703d8a2cd20971854b06@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=703d8a2cd20971854b06
>
> Signed-off-by: Bartlomiej Kubik <kubik.bartlomiej@gmail.com>
> ---
> 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
Hi,
Thank you for your suggestions.
On Wed, 24 Dec 2025 at 02:39, Baokun Li <libaokun1@huawei.com> wrote:
>
> 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@syzkaller.appspotmail.com
> > Reported-by: syzbot+703d8a2cd20971854b06@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=703d8a2cd20971854b06
> >
> > Signed-off-by: Bartlomiej Kubik <kubik.bartlomiej@gmail.com>
> > ---
> > 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.
Yes. That could introduce unnecessary zeroing in other paths.
> Therefore, I suspect something was missed in certain crypto-related
> initialization paths where the zeroing should have been handled instead.
I will try to fix this in the crypto-path only and send [PATCH v2].
>
> Cheers,
> Baokun
>
Best regards
Bartłomiej Kubik
On Sun, Dec 28, 2025 at 02:00:46PM +0100, Bartłomiej Kubik wrote:
> Hi,
>
> Thank you for your suggestions.
>
> On Wed, 24 Dec 2025 at 02:39, Baokun Li <libaokun1@huawei.com> wrote:
> >
> > 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@syzkaller.appspotmail.com
> > > Reported-by: syzbot+703d8a2cd20971854b06@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=703d8a2cd20971854b06
> > >
> > > Signed-off-by: Bartlomiej Kubik <kubik.bartlomiej@gmail.com>
> > > ---
> > > 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.
>
> Yes. That could introduce unnecessary zeroing in other paths.
>
> > Therefore, I suspect something was missed in certain crypto-related
> > initialization paths where the zeroing should have been handled instead.
>
> I will try to fix this in the crypto-path only and send [PATCH v2].
Please see https://lore.kernel.org/linux-ext4/20251210022202.GB4128@sol/
for my earlier analysis of this issue.
- Eric
© 2016 - 2026 Red Hat, Inc.