Re: [syzbot] [ext4] [fscrypt] KMSAN: uninit-value in fscrypt_crypt_data_unit

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Dec 09, 2025 at 06:22:02PM -0800, Eric Biggers wrote:
> On Tue, Dec 09, 2025 at 03:08:17AM -0800, syzbot wrote:
> > syzbot has found a reproducer for the following issue on:
> > 
> > HEAD commit:    a110f942672c Merge tag 'pinctrl-v6.19-1' of git://git.kern..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=17495992580000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=10d58c94af5f9772
> > dashboard link: https://syzkaller.appspot.com/bug?extid=7add5c56bc2a14145d20
> > compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1122aec2580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14012a1a580000
> 
> Simplified reproducer:
> 
>     rm -f image
>     mkdir -p mnt
>     mkfs.ext4 -O encrypt -b 1024 image 1M
>     mount image mnt -o test_dummy_encryption
>     dd if=/dev/urandom of=mnt/file bs=1 seek=1024 count=1
>     sync
> 
> It causes ext4 to encrypt uninitialized memory:
> 
>     BUG: KMSAN: uninit-value in crypto_aes_encrypt+0x511b/0x5260
>     [...]
>     fscrypt_encrypt_pagecache_blocks+0x309/0x6c0
>     ext4_bio_write_folio+0xd2f/0x2210
>     [...]
> 
> ext4_bio_write_folio() has:
> 
> 	/*
> 	 * If any blocks are being written to an encrypted file, encrypt them
> 	 * into a bounce page.  For simplicity, just encrypt until the last
> 	 * block which might be needed.  This may cause some unneeded blocks
> 	 * (e.g. holes) to be unnecessarily encrypted, but this is rare and
> 	 * can't happen in the common case of blocksize == PAGE_SIZE.
> 	 */
> 	if (fscrypt_inode_uses_fs_layer_crypto(inode)) {
> 		gfp_t gfp_flags = GFP_NOFS;
> 		unsigned int enc_bytes = round_up(len, i_blocksize(inode));
> 
> So I think that if a non-first block in a page is being written to disk
> and all preceding blocks in the page are holes, the (uninitialized)
> sections of the page corresponding to the holes are being encrypted too.
> 
> This is probably "benign", as ext4 doesn't do anything with the
> encrypted uninitialized data.  (Also note that this issue can occur only
> when block_size < PAGE_SIZE.)
> 
> I'm not yet sure how to proceed here.  We could make ext4 be more
> selective about encrypting the exact set of blocks in the page that are
> being written.  That would require support in fs/crypto/ for that.  We
> could use kmsan_unpoison_memory() to just suppress the warning.
> 
> Or, we could go forward with removing support for the "fs-layer crypto"
> from ext4 and only support blk-crypto (relying on blk-crypto-fallback
> for the software fallback).  The blk-crypto code path doesn't have this
> problem since it more closely ties the encryption to the actual write.
> It also works better with folios.

Hey waitaminute, are you planning to withdraw fscrypt from ext4?

(I might just not know enough about what blk-crypto is)

--D

> - Eric
>