* [syzbot] [crypto?] KMSAN: uninit-value in fscrypt_crypt_data_unit @ 2025-10-14 14:50 syzbot 2025-10-14 14:58 ` Aleksandr Nogikh 2025-12-09 11:08 ` [syzbot] [ext4] [fscrypt] " syzbot 0 siblings, 2 replies; 8+ messages in thread From: syzbot @ 2025-10-14 14:50 UTC (permalink / raw) To: davem, herbert, linux-crypto, linux-kernel, syzkaller-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [crypto?] KMSAN: uninit-value in fscrypt_crypt_data_unit 2025-10-14 14:50 [syzbot] [crypto?] KMSAN: uninit-value in fscrypt_crypt_data_unit syzbot @ 2025-10-14 14:58 ` Aleksandr Nogikh 2025-12-09 11:08 ` [syzbot] [ext4] [fscrypt] " syzbot 1 sibling, 0 replies; 8+ messages in thread From: Aleksandr Nogikh @ 2025-10-14 14:58 UTC (permalink / raw) To: syzbot Cc: davem, herbert, linux-crypto, linux-kernel, syzkaller-bugs, linux-ext4, linux-fscrypt, Eric Biggers #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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [ext4] [fscrypt] KMSAN: uninit-value in fscrypt_crypt_data_unit 2025-10-14 14:50 [syzbot] [crypto?] KMSAN: uninit-value in fscrypt_crypt_data_unit syzbot 2025-10-14 14:58 ` Aleksandr Nogikh @ 2025-12-09 11:08 ` syzbot 2025-12-10 2:22 ` Eric Biggers 1 sibling, 1 reply; 8+ messages in thread From: syzbot @ 2025-12-09 11:08 UTC (permalink / raw) To: davem, ebiggers, herbert, jaegeuk, linux-crypto, linux-ext4, linux-fscrypt, linux-kernel, syzkaller-bugs, tytso 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [ext4] [fscrypt] KMSAN: uninit-value in fscrypt_crypt_data_unit 2025-12-09 11:08 ` [syzbot] [ext4] [fscrypt] " syzbot @ 2025-12-10 2:22 ` Eric Biggers 2025-12-11 18:52 ` Darrick J. Wong 0 siblings, 1 reply; 8+ messages in thread From: Eric Biggers @ 2025-12-10 2:22 UTC (permalink / raw) To: syzbot Cc: davem, herbert, jaegeuk, linux-crypto, linux-ext4, linux-fscrypt, linux-kernel, syzkaller-bugs, tytso 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [ext4] [fscrypt] KMSAN: uninit-value in fscrypt_crypt_data_unit 2025-12-10 2:22 ` Eric Biggers @ 2025-12-11 18:52 ` Darrick J. Wong 2025-12-11 19:45 ` Eric Biggers 2025-12-12 5:16 ` Christoph Hellwig 0 siblings, 2 replies; 8+ messages in thread From: Darrick J. Wong @ 2025-12-11 18:52 UTC (permalink / raw) To: Eric Biggers Cc: syzbot, davem, herbert, jaegeuk, linux-crypto, linux-ext4, linux-fscrypt, linux-kernel, syzkaller-bugs, tytso, Neal Gompa 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [ext4] [fscrypt] KMSAN: uninit-value in fscrypt_crypt_data_unit 2025-12-11 18:52 ` Darrick J. Wong @ 2025-12-11 19:45 ` Eric Biggers 2025-12-11 22:19 ` Darrick J. Wong 2025-12-12 5:16 ` Christoph Hellwig 1 sibling, 1 reply; 8+ messages in thread From: Eric Biggers @ 2025-12-11 19:45 UTC (permalink / raw) To: Darrick J. Wong; +Cc: syzbot 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [ext4] [fscrypt] KMSAN: uninit-value in fscrypt_crypt_data_unit 2025-12-11 19:45 ` Eric Biggers @ 2025-12-11 22:19 ` Darrick J. Wong 0 siblings, 0 replies; 8+ messages in thread From: Darrick J. Wong @ 2025-12-11 22:19 UTC (permalink / raw) To: Eric Biggers; +Cc: syzbot 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [syzbot] [ext4] [fscrypt] KMSAN: uninit-value in fscrypt_crypt_data_unit 2025-12-11 18:52 ` Darrick J. Wong 2025-12-11 19:45 ` Eric Biggers @ 2025-12-12 5:16 ` Christoph Hellwig 1 sibling, 0 replies; 8+ messages in thread From: Christoph Hellwig @ 2025-12-12 5:16 UTC (permalink / raw) To: Darrick J. Wong Cc: Eric Biggers, syzbot, davem, herbert, jaegeuk, linux-crypto, linux-ext4, linux-fscrypt, linux-kernel, syzkaller-bugs, tytso, Neal Gompa 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* ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-12-12 5:16 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-10-14 14:50 [syzbot] [crypto?] KMSAN: uninit-value in fscrypt_crypt_data_unit syzbot 2025-10-14 14:58 ` Aleksandr Nogikh 2025-12-09 11:08 ` [syzbot] [ext4] [fscrypt] " syzbot 2025-12-10 2:22 ` Eric Biggers 2025-12-11 18:52 ` Darrick J. Wong 2025-12-11 19:45 ` Eric Biggers 2025-12-11 22:19 ` Darrick J. Wong 2025-12-12 5:16 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).