Re: [syzbot] [crypto?] KMSAN: uninit-value in fscrypt_crypt_data_unit

Re: [syzbot] [crypto?] KMSAN: uninit-value in fscrypt_crypt_data_unit

[Aleksandr Nogikh]

#syz set subsystems: ext4, fscrypt

On Tue, Oct 14, 2025 at 4:50 PM syzbot
<syzbot+7add5c56bc2a14145d20@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    3a8660878839 Linux 6.18-rc1
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13d25dcd980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=bbd3e7f3c2e28265
> 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
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/d996feb56093/disk-3a866087.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/fa6f6bc3b02a/vmlinux-3a866087.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/7571083a68d6/bzImage-3a866087.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+7add5c56bc2a14145d20@syzkaller.appspotmail.com
>
> EXT4-fs (loop5): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: writeback.
> =====================================================
> BUG: KMSAN: uninit-value in subshift lib/crypto/aes.c:150 [inline]
> BUG: KMSAN: uninit-value in aes_encrypt+0x1239/0x1960 lib/crypto/aes.c:283
>  subshift lib/crypto/aes.c:150 [inline]
>  aes_encrypt+0x1239/0x1960 lib/crypto/aes.c:283
>  aesti_encrypt+0x7d/0xf0 crypto/aes_ti.c:31
>  crypto_ecb_crypt crypto/ecb.c:23 [inline]
>  crypto_ecb_encrypt2+0x142/0x300 crypto/ecb.c:40
>  crypto_lskcipher_crypt_sg+0x3ac/0x930 crypto/lskcipher.c:188
>  crypto_lskcipher_encrypt_sg+0x8b/0xc0 crypto/lskcipher.c:207
>  crypto_skcipher_encrypt+0x111/0x1e0 crypto/skcipher.c:194
>  xts_encrypt+0x2e1/0x570 crypto/xts.c:269
>  crypto_skcipher_encrypt+0x18a/0x1e0 crypto/skcipher.c:195
>  fscrypt_crypt_data_unit+0x38e/0x590 fs/crypto/crypto.c:139
>  fscrypt_encrypt_pagecache_blocks+0x430/0x900 fs/crypto/crypto.c:197
>  ext4_bio_write_folio+0x1383/0x30d0 fs/ext4/page-io.c:552
>  mpage_submit_folio fs/ext4/inode.c:2080 [inline]
>  mpage_process_page_bufs+0xf1b/0x13e0 fs/ext4/inode.c:2191
>  mpage_prepare_extent_to_map+0x1792/0x2a10 fs/ext4/inode.c:2736
>  ext4_do_writepages+0x11b6/0x8020 fs/ext4/inode.c:2877
>  ext4_writepages+0x338/0x870 fs/ext4/inode.c:3025
>  do_writepages+0x3f2/0x860 mm/page-writeback.c:2604
>  filemap_fdatawrite_wbc mm/filemap.c:389 [inline]
>  __filemap_fdatawrite_range mm/filemap.c:422 [inline]
>  file_write_and_wait_range+0x6f0/0x7d0 mm/filemap.c:797
>  generic_buffers_fsync_noflush+0x79/0x3c0 fs/buffer.c:609
>  ext4_fsync_nojournal fs/ext4/fsync.c:88 [inline]
>  ext4_sync_file+0x587/0x12f0 fs/ext4/fsync.c:147
>  vfs_fsync_range+0x1a1/0x240 fs/sync.c:187
>  generic_write_sync include/linux/fs.h:3046 [inline]
>  ext4_buffered_write_iter+0xae9/0xce0 fs/ext4/file.c:305
>  ext4_file_write_iter+0x2a2/0x3d90 fs/ext4/file.c:-1
>  new_sync_write fs/read_write.c:593 [inline]
>  vfs_write+0xbe2/0x15d0 fs/read_write.c:686
>  ksys_pwrite64 fs/read_write.c:793 [inline]
>  __do_sys_pwrite64 fs/read_write.c:801 [inline]
>  __se_sys_pwrite64 fs/read_write.c:798 [inline]
>  __x64_sys_pwrite64+0x2ab/0x3b0 fs/read_write.c:798
>  x64_sys_call+0xe77/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:19
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Uninit was stored to memory at:
>  le128_xor include/crypto/b128ops.h:69 [inline]
>  xts_xor_tweak+0x566/0xbd0 crypto/xts.c:123
>  xts_xor_tweak_pre crypto/xts.c:135 [inline]
>  xts_encrypt+0x278/0x570 crypto/xts.c:268
>  crypto_skcipher_encrypt+0x18a/0x1e0 crypto/skcipher.c:195
>  fscrypt_crypt_data_unit+0x38e/0x590 fs/crypto/crypto.c:139
>  fscrypt_encrypt_pagecache_blocks+0x430/0x900 fs/crypto/crypto.c:197
>  ext4_bio_write_folio+0x1383/0x30d0 fs/ext4/page-io.c:552
>  mpage_submit_folio fs/ext4/inode.c:2080 [inline]
>  mpage_process_page_bufs+0xf1b/0x13e0 fs/ext4/inode.c:2191
>  mpage_prepare_extent_to_map+0x1792/0x2a10 fs/ext4/inode.c:2736
>  ext4_do_writepages+0x11b6/0x8020 fs/ext4/inode.c:2877
>  ext4_writepages+0x338/0x870 fs/ext4/inode.c:3025
>  do_writepages+0x3f2/0x860 mm/page-writeback.c:2604
>  filemap_fdatawrite_wbc mm/filemap.c:389 [inline]
>  __filemap_fdatawrite_range mm/filemap.c:422 [inline]
>  file_write_and_wait_range+0x6f0/0x7d0 mm/filemap.c:797
>  generic_buffers_fsync_noflush+0x79/0x3c0 fs/buffer.c:609
>  ext4_fsync_nojournal fs/ext4/fsync.c:88 [inline]
>  ext4_sync_file+0x587/0x12f0 fs/ext4/fsync.c:147
>  vfs_fsync_range+0x1a1/0x240 fs/sync.c:187
>  generic_write_sync include/linux/fs.h:3046 [inline]
>  ext4_buffered_write_iter+0xae9/0xce0 fs/ext4/file.c:305
>  ext4_file_write_iter+0x2a2/0x3d90 fs/ext4/file.c:-1
>  new_sync_write fs/read_write.c:593 [inline]
>  vfs_write+0xbe2/0x15d0 fs/read_write.c:686
>  ksys_pwrite64 fs/read_write.c:793 [inline]
>  __do_sys_pwrite64 fs/read_write.c:801 [inline]
>  __se_sys_pwrite64 fs/read_write.c:798 [inline]
>  __x64_sys_pwrite64+0x2ab/0x3b0 fs/read_write.c:798
>  x64_sys_call+0xe77/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:19
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Uninit was created at:
>  __alloc_frozen_pages_noprof+0x689/0xf00 mm/page_alloc.c:5206
>  alloc_pages_mpol+0x328/0x860 mm/mempolicy.c:2416
>  alloc_frozen_pages_noprof mm/mempolicy.c:2487 [inline]
>  alloc_pages_noprof mm/mempolicy.c:2507 [inline]
>  folio_alloc_noprof+0x109/0x360 mm/mempolicy.c:2517
>  filemap_alloc_folio_noprof+0x9d/0x420 mm/filemap.c:1020
>  __filemap_get_folio+0xb45/0x1930 mm/filemap.c:2012
>  write_begin_get_folio include/linux/pagemap.h:784 [inline]
>  ext4_write_begin+0x6d9/0x2d70 fs/ext4/inode.c:1318
>  generic_perform_write+0x365/0x1050 mm/filemap.c:4242
>  ext4_buffered_write_iter+0x61a/0xce0 fs/ext4/file.c:299
>  ext4_file_write_iter+0x2a2/0x3d90 fs/ext4/file.c:-1
>  new_sync_write fs/read_write.c:593 [inline]
>  vfs_write+0xbe2/0x15d0 fs/read_write.c:686
>  ksys_pwrite64 fs/read_write.c:793 [inline]
>  __do_sys_pwrite64 fs/read_write.c:801 [inline]
>  __se_sys_pwrite64 fs/read_write.c:798 [inline]
>  __x64_sys_pwrite64+0x2ab/0x3b0 fs/read_write.c:798
>  x64_sys_call+0xe77/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:19
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> CPU: 1 UID: 0 PID: 5879 Comm: syz.5.3882 Tainted: G        W           syzkaller #0 PREEMPT(none)
> Tainted: [W]=WARN
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
> =====================================================
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-bugs/68ee633c.050a0220.1186a4.002a.GAE%40google.com.

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

[syzbot]

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/905b868d0b1d/disk-a110f942.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/aa7281cd9720/vmlinux-a110f942.xz
kernel image: https://storage.googleapis.com/syzbot-assets/1420de8a7da2/bzImage-a110f942.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/1e40f788aa89/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=1622aec2580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7add5c56bc2a14145d20@syzkaller.appspotmail.com

=====================================================
BUG: KMSAN: uninit-value in subshift lib/crypto/aes.c:150 [inline]
BUG: KMSAN: uninit-value in aes_encrypt+0x1239/0x1960 lib/crypto/aes.c:283
 subshift lib/crypto/aes.c:150 [inline]
 aes_encrypt+0x1239/0x1960 lib/crypto/aes.c:283
 aesti_encrypt+0x7d/0xf0 crypto/aes_ti.c:31
 crypto_ecb_crypt crypto/ecb.c:23 [inline]
 crypto_ecb_encrypt2+0x142/0x300 crypto/ecb.c:40
 crypto_lskcipher_crypt_sg+0x3ac/0x930 crypto/lskcipher.c:188
 crypto_lskcipher_encrypt_sg+0x8b/0xc0 crypto/lskcipher.c:207
 crypto_skcipher_encrypt+0x111/0x1e0 crypto/skcipher.c:443
 xts_encrypt+0x2e1/0x570 crypto/xts.c:269
 crypto_skcipher_encrypt+0x18a/0x1e0 crypto/skcipher.c:444
 fscrypt_crypt_data_unit+0x38e/0x590 fs/crypto/crypto.c:139
 fscrypt_encrypt_pagecache_blocks+0x430/0x900 fs/crypto/crypto.c:197
 ext4_bio_write_folio+0x1383/0x30d0 fs/ext4/page-io.c:552
 mpage_submit_folio+0x399/0x3d0 fs/ext4/inode.c:2087
 mpage_process_page_bufs+0xaef/0xf50 fs/ext4/inode.c:2198
 mpage_prepare_extent_to_map+0x175d/0x2660 fs/ext4/inode.c:2737
 ext4_do_writepages+0x1aa1/0x77a0 fs/ext4/inode.c:2930
 ext4_writepages+0x338/0x870 fs/ext4/inode.c:3026
 do_writepages+0x3f2/0x860 mm/page-writeback.c:2598
 __writeback_single_inode+0x101/0x1190 fs/fs-writeback.c:1737
 writeback_sb_inodes+0xb2d/0x1f10 fs/fs-writeback.c:2030
 wb_writeback+0x4ce/0xc00 fs/fs-writeback.c:2216
 wb_do_writeback fs/fs-writeback.c:2363 [inline]
 wb_workfn+0x397/0x1910 fs/fs-writeback.c:2403
 process_one_work kernel/workqueue.c:3257 [inline]
 process_scheduled_works+0xb91/0x1d80 kernel/workqueue.c:3340
 worker_thread+0xedf/0x1590 kernel/workqueue.c:3421
 kthread+0xd5c/0xf00 kernel/kthread.c:463
 ret_from_fork+0x208/0x710 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246

Uninit was stored to memory at:
 le128_xor include/crypto/b128ops.h:69 [inline]
 xts_xor_tweak+0x566/0xbd0 crypto/xts.c:123
 xts_xor_tweak_pre crypto/xts.c:135 [inline]
 xts_encrypt+0x278/0x570 crypto/xts.c:268
 crypto_skcipher_encrypt+0x18a/0x1e0 crypto/skcipher.c:444
 fscrypt_crypt_data_unit+0x38e/0x590 fs/crypto/crypto.c:139
 fscrypt_encrypt_pagecache_blocks+0x430/0x900 fs/crypto/crypto.c:197
 ext4_bio_write_folio+0x1383/0x30d0 fs/ext4/page-io.c:552
 mpage_submit_folio+0x399/0x3d0 fs/ext4/inode.c:2087
 mpage_process_page_bufs+0xaef/0xf50 fs/ext4/inode.c:2198
 mpage_prepare_extent_to_map+0x175d/0x2660 fs/ext4/inode.c:2737
 ext4_do_writepages+0x1aa1/0x77a0 fs/ext4/inode.c:2930
 ext4_writepages+0x338/0x870 fs/ext4/inode.c:3026
 do_writepages+0x3f2/0x860 mm/page-writeback.c:2598
 __writeback_single_inode+0x101/0x1190 fs/fs-writeback.c:1737
 writeback_sb_inodes+0xb2d/0x1f10 fs/fs-writeback.c:2030
 wb_writeback+0x4ce/0xc00 fs/fs-writeback.c:2216
 wb_do_writeback fs/fs-writeback.c:2363 [inline]
 wb_workfn+0x397/0x1910 fs/fs-writeback.c:2403
 process_one_work kernel/workqueue.c:3257 [inline]
 process_scheduled_works+0xb91/0x1d80 kernel/workqueue.c:3340
 worker_thread+0xedf/0x1590 kernel/workqueue.c:3421
 kthread+0xd5c/0xf00 kernel/kthread.c:463
 ret_from_fork+0x208/0x710 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246

Uninit was created at:
 __alloc_frozen_pages_noprof+0x421/0xab0 mm/page_alloc.c:5233
 alloc_pages_mpol+0x328/0x860 mm/mempolicy.c:2486
 alloc_frozen_pages_noprof mm/mempolicy.c:2557 [inline]
 alloc_pages_noprof mm/mempolicy.c:2577 [inline]
 folio_alloc_noprof+0x109/0x360 mm/mempolicy.c:2587
 filemap_alloc_folio_noprof+0xda/0x480 mm/filemap.c:1013
 __filemap_get_folio_mpol+0xb4f/0x1960 mm/filemap.c:2006
 __filemap_get_folio include/linux/pagemap.h:763 [inline]
 write_begin_get_folio include/linux/pagemap.h:789 [inline]
 ext4_write_begin+0x6d3/0x2d70 fs/ext4/inode.c:1323
 generic_perform_write+0x365/0x1050 mm/filemap.c:4314
 ext4_buffered_write_iter+0x61a/0xce0 fs/ext4/file.c:299
 ext4_file_write_iter+0x2a2/0x3d90 fs/ext4/file.c:-1
 aio_write+0x704/0xa10 fs/aio.c:1634
 __io_submit_one fs/aio.c:-1 [inline]
 io_submit_one+0x260e/0x3450 fs/aio.c:2053
 __do_sys_io_submit fs/aio.c:2112 [inline]
 __se_sys_io_submit+0x27c/0x6a0 fs/aio.c:2082
 __x64_sys_io_submit+0x97/0xe0 fs/aio.c:2082
 x64_sys_call+0x3b5f/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:210
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xd9/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 1 UID: 0 PID: 1143 Comm: kworker/u8:8 Not tainted syzkaller #0 PREEMPT(none) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Workqueue: writeback wb_workfn (flush-7:0)
=====================================================


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

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

[Eric Biggers]

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.

- Eric

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

[Darrick J. Wong]

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
> 

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

[Eric Biggers]

On Thu, Dec 11, 2025 at 10:52:15AM -0800, Darrick J. Wong wrote:
> 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)
> 

ext4 (and also f2fs) has two different implementations of file contents
en/decryption: one where the filesystem directly calls the crypto
functions to en/decrypt file contents, and one where the filesystem
instead adds a bio_crypt_ctx to the bios it submits, causing the block
layer to handle the en/decryption (via either inline crypto hardware or
blk-crypto-fallback).  See the "Inline encryption support" section of
Documentation/filesystems/fscrypt.rst.

These correspond to fscrypt_inode_uses_fs_layer_crypto() and
fscrypt_inode_uses_inline_crypto() in the code.  The "fs-layer"
implementation is used by default, while the inline crypto
implementation is used when the 'inlinecrypt' mount option is used.

It's just an implementation detail and doesn't affect the end result.

Note that "fscrypt" is the name for the overall ext4/f2fs/etc encryption
feature, which both these implementations are part of.

I'm talking about possibly removing the first of these file contents
encryption implementations, which again are just implementation details,
so that we standardize on just the blk-crypto one.

Again, this KMSAN warning is specific to the first implementation.  I.e.
it doesn't appear when the inlinecrypt mount option is used.

- Eric

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

[Darrick J. Wong]

On Thu, Dec 11, 2025 at 07:45:02PM +0000, Eric Biggers wrote:
> On Thu, Dec 11, 2025 at 10:52:15AM -0800, Darrick J. Wong wrote:
> > 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)
> > 
> 
> ext4 (and also f2fs) has two different implementations of file contents
> en/decryption: one where the filesystem directly calls the crypto
> functions to en/decrypt file contents, and one where the filesystem
> instead adds a bio_crypt_ctx to the bios it submits, causing the block
> layer to handle the en/decryption (via either inline crypto hardware or
> blk-crypto-fallback).  See the "Inline encryption support" section of
> Documentation/filesystems/fscrypt.rst.
> 
> These correspond to fscrypt_inode_uses_fs_layer_crypto() and
> fscrypt_inode_uses_inline_crypto() in the code.  The "fs-layer"
> implementation is used by default, while the inline crypto
> implementation is used when the 'inlinecrypt' mount option is used.
> 
> It's just an implementation detail and doesn't affect the end result.
> 
> Note that "fscrypt" is the name for the overall ext4/f2fs/etc encryption
> feature, which both these implementations are part of.
> 
> I'm talking about possibly removing the first of these file contents
> encryption implementations, which again are just implementation details,
> so that we standardize on just the blk-crypto one.

Ooh, I bet that will integrate better with iomap, whenever someone gets
around to attempting the first port. :)

--D

> Again, this KMSAN warning is specific to the first implementation.  I.e.
> it doesn't appear when the inlinecrypt mount option is used.
> 
> - Eric
> 

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

[Christoph Hellwig]

On Thu, Dec 11, 2025 at 10:52:15AM -0800, Darrick J. Wong wrote:
> Hey waitaminute, are you planning to withdraw fscrypt from ext4?

No really, just forcing to use one of the two current implementations
of the I/O path.

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

block/blk-crypto*