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 >
