* [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).