* [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer @ 2023-06-25 2:21 syzbot 2023-06-29 3:57 ` Theodore Ts'o 0 siblings, 1 reply; 5+ messages in thread From: syzbot @ 2023-06-25 2:21 UTC (permalink / raw) To: adilger.kernel, linux-ext4, linux-fsdevel, linux-kernel, syzkaller-bugs, tytso Hello, syzbot found the following issue on: HEAD commit: f7efed9f38f8 Add linux-next specific files for 20230616 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=152e89f3280000 kernel config: https://syzkaller.appspot.com/x/.config?x=60b1a32485a77c16 dashboard link: https://syzkaller.appspot.com/bug?extid=94a8c779c6b238870393 compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116af1eb280000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14e22d2f280000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/95bcbee03439/disk-f7efed9f.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/6fd295caa4de/vmlinux-f7efed9f.xz kernel image: https://storage.googleapis.com/syzbot-assets/69c038a34b5f/bzImage-f7efed9f.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+94a8c779c6b238870393@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdffffc00000000c5: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000628-0x000000000000062f] CPU: 1 PID: 5032 Comm: syz-executor136 Not tainted 6.4.0-rc6-next-20230616-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 RIP: 0010:EXT4_SB fs/ext4/ext4.h:1741 [inline] RIP: 0010:ext4_add_complete_io fs/ext4/page-io.c:225 [inline] RIP: 0010:ext4_put_io_end_defer fs/ext4/page-io.c:297 [inline] RIP: 0010:ext4_put_io_end_defer+0x162/0x460 fs/ext4/page-io.c:289 Code: c1 ea 03 80 3c 02 00 0f 85 b9 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 6c 24 28 49 8d bd 28 06 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 02 00 00 f7 d3 31 ff 4d 8b ad 28 06 00 00 83 RSP: 0000:ffffc900001e0cb8 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 0000000000000100 RDX: 00000000000000c5 RSI: ffffffff8234a5d2 RDI: 0000000000000628 RBP: ffff888076af2180 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88807f3ee6b0 R13: 0000000000000000 R14: ffff8880213eb400 R15: ffff8880213eb3d8 FS: 0000555556fc0300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000002a18c000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ext4_end_bio+0x282/0x560 fs/ext4/page-io.c:359 bio_endio+0x589/0x690 block/bio.c:1617 req_bio_endio block/blk-mq.c:766 [inline] blk_update_request+0x56b/0x14f0 block/blk-mq.c:911 scsi_end_request+0x7a/0xa20 drivers/scsi/scsi_lib.c:541 scsi_io_completion+0x17b/0x1770 drivers/scsi/scsi_lib.c:978 scsi_complete+0x126/0x3b0 drivers/scsi/scsi_lib.c:1442 blk_complete_reqs+0xb3/0xf0 block/blk-mq.c:1110 __do_softirq+0x1d4/0x905 kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1109 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:645 RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:200 Code: f6 da 90 02 66 0f 1f 44 00 00 f3 0f 1e fa 48 8b be b0 01 00 00 e8 b0 ff ff ff 31 c0 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 <f3> 0f 1e fa 65 8b 05 1d 58 7f 7e 89 c1 48 8b 34 24 81 e1 00 01 00 RSP: 0000:ffffc900039df500 EFLAGS: 00000293 RAX: 0000000000000000 RBX: 0000000000000200 RCX: 0000000000000000 RDX: ffff8880265c1dc0 RSI: ffffffff81687255 RDI: 0000000000000007 RBP: ffffffff8d4ba518 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000200 R11: 00000000000000d4 R12: 0000000000000000 R13: ffffffff8d4ba4c0 R14: dffffc0000000000 R15: 0000000000000001 console_emit_next_record arch/x86/include/asm/irqflags.h:42 [inline] console_flush_all+0x61b/0xcc0 kernel/printk/printk.c:2933 console_unlock+0xb8/0x1f0 kernel/printk/printk.c:3007 vprintk_emit+0x1bd/0x600 kernel/printk/printk.c:2307 vprintk+0x84/0xa0 kernel/printk/printk_safe.c:50 _printk+0xbf/0xf0 kernel/printk/printk.c:2328 __list_add_valid+0xb9/0x100 lib/list_debug.c:30 __list_add include/linux/list.h:69 [inline] list_add_tail include/linux/list.h:102 [inline] list_lru_add+0x298/0x520 mm/list_lru.c:129 d_lru_add fs/dcache.c:431 [inline] retain_dentry fs/dcache.c:685 [inline] dput+0x806/0xe10 fs/dcache.c:908 do_unlinkat+0x3f3/0x680 fs/namei.c:4398 do_coredump+0x1836/0x4040 fs/coredump.c:675 get_signal+0x1c16/0x25f0 kernel/signal.c:2863 arch_do_signal_or_restart+0x79/0x5c0 arch/x86/kernel/signal.c:306 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x11f/0x240 kernel/entry/common.c:204 irqentry_exit_to_user_mode+0x9/0x40 kernel/entry/common.c:310 exc_page_fault+0xc0/0x170 arch/x86/mm/fault.c:1593 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0033:0x7f7d17d7ce13 ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5032 at arch/x86/mm/tlb.c:1295 nmi_uaccess_okay+0x99/0xb0 arch/x86/mm/tlb.c:1295 Modules linked in: CPU: 1 PID: 5032 Comm: syz-executor136 Not tainted 6.4.0-rc6-next-20230616-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 RIP: 0010:nmi_uaccess_okay+0x99/0xb0 arch/x86/mm/tlb.c:1295 Code: d8 48 ba 00 f0 ff ff ff ff 0f 00 41 b8 01 00 00 00 48 21 d0 48 ba 00 00 00 00 80 88 ff ff 48 01 d0 48 39 85 80 00 00 00 74 b0 <0f> 0b eb ac 0f 0b eb a0 e8 ba d5 9d 00 eb 8d e8 b3 d5 9d 00 eb be RSP: 0000:ffffc900001e0938 EFLAGS: 00010007 RAX: ffff88802a18c000 RBX: ffff88807f50b600 RCX: 0000000000000100 RDX: ffff888000000000 RSI: ffffffff8a11653d RDI: ffff88807f50b680 RBP: ffff88807f50b600 R08: 0000000000000001 R09: 00007f7d17d7cde9 R10: 00007f7d17d7ce29 R11: 0000000000096001 R12: 00007f7d17d7cde9 R13: 00007f7d17d7ce29 R14: 0000000000000000 R15: ffffc900001e0aa8 FS: 0000555556fc0300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000002a18c000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> copy_from_user_nmi+0x62/0x150 arch/x86/lib/usercopy.c:39 copy_code arch/x86/kernel/dumpstack.c:91 [inline] show_opcodes+0x5d/0xd0 arch/x86/kernel/dumpstack.c:121 show_ip arch/x86/kernel/dumpstack.c:144 [inline] show_iret_regs+0x30/0x60 arch/x86/kernel/dumpstack.c:149 __show_regs+0x22/0x680 arch/x86/kernel/process_64.c:75 show_trace_log_lvl+0x255/0x390 arch/x86/kernel/dumpstack.c:301 __die_body arch/x86/kernel/dumpstack.c:420 [inline] die_addr+0x3c/0xa0 arch/x86/kernel/dumpstack.c:460 __exc_general_protection arch/x86/kernel/traps.c:783 [inline] exc_general_protection+0x129/0x230 arch/x86/kernel/traps.c:728 asm_exc_general_protection+0x26/0x30 arch/x86/include/asm/idtentry.h:564 RIP: 0010:EXT4_SB fs/ext4/ext4.h:1741 [inline] RIP: 0010:ext4_add_complete_io fs/ext4/page-io.c:225 [inline] RIP: 0010:ext4_put_io_end_defer fs/ext4/page-io.c:297 [inline] RIP: 0010:ext4_put_io_end_defer+0x162/0x460 fs/ext4/page-io.c:289 Code: c1 ea 03 80 3c 02 00 0f 85 b9 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 6c 24 28 49 8d bd 28 06 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 02 00 00 f7 d3 31 ff 4d 8b ad 28 06 00 00 83 RSP: 0000:ffffc900001e0cb8 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 0000000000000100 RDX: 00000000000000c5 RSI: ffffffff8234a5d2 RDI: 0000000000000628 RBP: ffff888076af2180 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88807f3ee6b0 R13: 0000000000000000 R14: ffff8880213eb400 R15: ffff8880213eb3d8 ext4_end_bio+0x282/0x560 fs/ext4/page-io.c:359 bio_endio+0x589/0x690 block/bio.c:1617 req_bio_endio block/blk-mq.c:766 [inline] blk_update_request+0x56b/0x14f0 block/blk-mq.c:911 scsi_end_request+0x7a/0xa20 drivers/scsi/scsi_lib.c:541 scsi_io_completion+0x17b/0x1770 drivers/scsi/scsi_lib.c:978 scsi_complete+0x126/0x3b0 drivers/scsi/scsi_lib.c:1442 blk_complete_reqs+0xb3/0xf0 block/blk-mq.c:1110 __do_softirq+0x1d4/0x905 kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1109 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:645 RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:200 Code: f6 da 90 02 66 0f 1f 44 00 00 f3 0f 1e fa 48 8b be b0 01 00 00 e8 b0 ff ff ff 31 c0 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 <f3> 0f 1e fa 65 8b 05 1d 58 7f 7e 89 c1 48 8b 34 24 81 e1 00 01 00 RSP: 0000:ffffc900039df500 EFLAGS: 00000293 RAX: 0000000000000000 RBX: 0000000000000200 RCX: 0000000000000000 RDX: ffff8880265c1dc0 RSI: ffffffff81687255 RDI: 0000000000000007 RBP: ffffffff8d4ba518 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000200 R11: 00000000000000d4 R12: 0000000000000000 R13: ffffffff8d4ba4c0 R14: dffffc0000000000 R15: 0000000000000001 console_emit_next_record arch/x86/include/asm/irqflags.h:42 [inline] console_flush_all+0x61b/0xcc0 kernel/printk/printk.c:2933 console_unlock+0xb8/0x1f0 kernel/printk/printk.c:3007 vprintk_emit+0x1bd/0x600 kernel/printk/printk.c:2307 vprintk+0x84/0xa0 kernel/printk/printk_safe.c:50 _printk+0xbf/0xf0 kernel/printk/printk.c:2328 __list_add_valid+0xb9/0x100 lib/list_debug.c:30 __list_add include/linux/list.h:69 [inline] list_add_tail include/linux/list.h:102 [inline] list_lru_add+0x298/0x520 mm/list_lru.c:129 d_lru_add fs/dcache.c:431 [inline] retain_dentry fs/dcache.c:685 [inline] dput+0x806/0xe10 fs/dcache.c:908 do_unlinkat+0x3f3/0x680 fs/namei.c:4398 do_coredump+0x1836/0x4040 fs/coredump.c:675 get_signal+0x1c16/0x25f0 kernel/signal.c:2863 arch_do_signal_or_restart+0x79/0x5c0 arch/x86/kernel/signal.c:306 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x11f/0x240 kernel/entry/common.c:204 irqentry_exit_to_user_mode+0x9/0x40 kernel/entry/common.c:310 exc_page_fault+0xc0/0x170 arch/x86/mm/fault.c:1593 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0033:0x7f7d17d7ce13 Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RSP: 002b:00007ffecfb11b00 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000014024 RCX: 00007f7d17d95071 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000000001b1 R08: 0000000000000000 R09: 00007ffecfbcc080 R10: 0000000000000000 R11: 0000000000000000 R12: 00007ffecfb11b64 R13: 00007ffecfb11bc0 R14: 00000000000000d7 R15: 431bde82d7b634db </TASK> ---------------- Code disassembly (best guess): 0: c1 ea 03 shr $0x3,%edx 3: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) 7: 0f 85 b9 02 00 00 jne 0x2c6 d: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax 14: fc ff df 17: 4d 8b 6c 24 28 mov 0x28(%r12),%r13 1c: 49 8d bd 28 06 00 00 lea 0x628(%r13),%rdi 23: 48 89 fa mov %rdi,%rdx 26: 48 c1 ea 03 shr $0x3,%rdx * 2a: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction 2e: 0f 85 c0 02 00 00 jne 0x2f4 34: f7 d3 not %ebx 36: 31 ff xor %edi,%edi 38: 4d 8b ad 28 06 00 00 mov 0x628(%r13),%r13 3f: 83 .byte 0x83 --- 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 bug is already fixed, let syzbot know by replying with: #syz fix: exact-commit-title 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. If you want to change bug's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the bug is a duplicate of another bug, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer 2023-06-25 2:21 [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer syzbot @ 2023-06-29 3:57 ` Theodore Ts'o 2023-06-30 7:41 ` Eric Biggers 0 siblings, 1 reply; 5+ messages in thread From: Theodore Ts'o @ 2023-06-29 3:57 UTC (permalink / raw) To: syzbot Cc: adilger.kernel, linux-ext4, linux-fsdevel, linux-kernel, linux-crypto, syzkaller-bugs #syz set subsystems: crypto On Sat, Jun 24, 2023 at 07:21:44PM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: f7efed9f38f8 Add linux-next specific files for 20230616 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=152e89f3280000 > kernel config: https://syzkaller.appspot.com/x/.config?x=60b1a32485a77c16 > dashboard link: https://syzkaller.appspot.com/bug?extid=94a8c779c6b238870393 > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116af1eb280000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14e22d2f280000 If you look at the reproducer, it's creating an AF_ALG (algorithm) socket and messing with it. This is easier to see in the syz reproducer, but you can see exactly what it's doing in the C reproducer above: # https://syzkaller.appspot.com/bug?id=4ee7656695de92cbd5820111379ae0698af0f475 # See https://goo.gl/kgGztJ for information about syzkaller reproducers. #{"threaded":true,"repeat":true,"procs":1,"slowdown":1,"sandbox":"none","sandbox_arg":0,"netdev":true,"binfmt_misc":true,"close_fds":true,"vhci":true,"ieee802154":true,"sysctl":true,"swap":true,"tmpdir":true} r0 = socket$alg(0x26, 0x5, 0x0) bind$alg(r0, &(0x7f0000000280)={0x26, 'hash\x00', 0x0, 0x0, 'sha3-256-generic\x00'}, 0x58) r1 = accept4(r0, 0x0, 0x0, 0x0) recvmmsg$unix(r1, &(0x7f0000003700)=[{{0x0, 0x700, 0x0}}], 0x600, 0x0, 0x0) sendmsg$can_bcm(r1, &(0x7f0000000180)={0x0, 0x0, &(0x7f0000000140)={0x0}}, 0x400c800) (0x26 is 38, or AF_ALG) From looking at the stack trace, it looks like this is triggering a coredump, which presumably is the ext4 write that triggers the GPF in ext4_put_io_end_defer. But given that the syz and C reproducer isn't doing anything ext4 related at all, and it's purely trying to use the AF_ALG socket to calculate SHA3 in the kernel (and the greek chorus cries out, "WHY?"[1]), I'm going to send this over to the crypto folks to investigate. Cheers, - Ted [1] TIL that AF_ALG exists. Inquiring minds want to know: * Why do we expose the AF_ALG userspace interface? * Who uses it? * Why do they use it? * Is there a CONFIG option to disable it in the name of decreasing the attack surface of the kernel? * If not, should we add one? :-) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer 2023-06-29 3:57 ` Theodore Ts'o @ 2023-06-30 7:41 ` Eric Biggers 2023-06-30 7:46 ` Eric Biggers 0 siblings, 1 reply; 5+ messages in thread From: Eric Biggers @ 2023-06-30 7:41 UTC (permalink / raw) To: Theodore Ts'o Cc: syzbot, adilger.kernel, linux-ext4, linux-fsdevel, linux-kernel, linux-crypto, syzkaller-bugs, David Howells On Wed, Jun 28, 2023 at 11:57:14PM -0400, Theodore Ts'o wrote: > #syz set subsystems: crypto > > On Sat, Jun 24, 2023 at 07:21:44PM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: f7efed9f38f8 Add linux-next specific files for 20230616 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=152e89f3280000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=60b1a32485a77c16 > > dashboard link: https://syzkaller.appspot.com/bug?extid=94a8c779c6b238870393 > > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116af1eb280000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14e22d2f280000 > > If you look at the reproducer, it's creating an AF_ALG (algorithm) > socket and messing with it. This is easier to see in the syz > reproducer, but you can see exactly what it's doing in the C > reproducer above: > > # https://syzkaller.appspot.com/bug?id=4ee7656695de92cbd5820111379ae0698af0f475 > # See https://goo.gl/kgGztJ for information about syzkaller reproducers. > #{"threaded":true,"repeat":true,"procs":1,"slowdown":1,"sandbox":"none","sandbox_arg":0,"netdev":true,"binfmt_misc":true,"close_fds":true,"vhci":true,"ieee802154":true,"sysctl":true,"swap":true,"tmpdir":true} > r0 = socket$alg(0x26, 0x5, 0x0) > bind$alg(r0, &(0x7f0000000280)={0x26, 'hash\x00', 0x0, 0x0, 'sha3-256-generic\x00'}, 0x58) > r1 = accept4(r0, 0x0, 0x0, 0x0) > recvmmsg$unix(r1, &(0x7f0000003700)=[{{0x0, 0x700, 0x0}}], 0x600, 0x0, 0x0) > sendmsg$can_bcm(r1, &(0x7f0000000180)={0x0, 0x0, &(0x7f0000000140)={0x0}}, 0x400c800) > > (0x26 is 38, or AF_ALG) > > From looking at the stack trace, it looks like this is triggering a > coredump, which presumably is the ext4 write that triggers the GPF in > ext4_put_io_end_defer. But given that the syz and C reproducer isn't > doing anything ext4 related at all, and it's purely trying to use the > AF_ALG socket to calculate SHA3 in the kernel (and the greek chorus > cries out, "WHY?"[1]), I'm going to send this over to the crypto folks to > investigate. Just a couple weeks ago, commit c662b043cdca ("crypto: af_alg/hash: Support MSG_SPLICE_PAGES") had many syzbot reports against it. This particular report is against next-20230616 which didn't include the fix commit b6d972f68983 ("crypto: af_alg/hash: Fix recvmsg() after sendmsg(MSG_MORE)"). So there's a high chance this report is no longer valid. I'll go ahead and invalidate it: #syz invalid > > Cheers, > > - Ted > > [1] TIL that AF_ALG exists. Inquiring minds want to know: > * Why do we expose the AF_ALG userspace interface? > * Who uses it? > * Why do they use it? > * Is there a CONFIG option to disable it in the name of decreasing > the attack surface of the kernel? > * If not, should we add one? :-) AF_ALG has existed since 2010. My understanding that its original purpose was to expose hardware crypto accelerators to userspace. Unfortunately, support for exposing *any* crypto algorithm was included as well, which IMO was a mistake. There are quite a few different userspace programs that use AF_ALG purely to get at the CPU-based algorithm implementations, without any sort of intention to use hardware crypto accelerator. Probably because it seemed "easy". Or "better" because everything in the kernel is better, right? It's controlled by the CONFIG_CRYPTO_USER_API_* options, with the hash support in particular controlled by CONFIG_CRYPTO_USER_API_HASH. Though good luck disabling it on most systems, as systemd depends on it... - Eric ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer 2023-06-30 7:41 ` Eric Biggers @ 2023-06-30 7:46 ` Eric Biggers 2023-06-30 17:13 ` Theodore Ts'o 0 siblings, 1 reply; 5+ messages in thread From: Eric Biggers @ 2023-06-30 7:46 UTC (permalink / raw) To: Theodore Ts'o Cc: syzbot, adilger.kernel, linux-ext4, linux-fsdevel, linux-kernel, linux-crypto, syzkaller-bugs, David Howells On Fri, Jun 30, 2023 at 12:41:11AM -0700, Eric Biggers wrote: > On Wed, Jun 28, 2023 at 11:57:14PM -0400, Theodore Ts'o wrote: > > #syz set subsystems: crypto > > > > On Sat, Jun 24, 2023 at 07:21:44PM -0700, syzbot wrote: > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: f7efed9f38f8 Add linux-next specific files for 20230616 > > > git tree: linux-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=152e89f3280000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=60b1a32485a77c16 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=94a8c779c6b238870393 > > > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116af1eb280000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14e22d2f280000 > > > > If you look at the reproducer, it's creating an AF_ALG (algorithm) > > socket and messing with it. This is easier to see in the syz > > reproducer, but you can see exactly what it's doing in the C > > reproducer above: > > > > # https://syzkaller.appspot.com/bug?id=4ee7656695de92cbd5820111379ae0698af0f475 > > # See https://goo.gl/kgGztJ for information about syzkaller reproducers. > > #{"threaded":true,"repeat":true,"procs":1,"slowdown":1,"sandbox":"none","sandbox_arg":0,"netdev":true,"binfmt_misc":true,"close_fds":true,"vhci":true,"ieee802154":true,"sysctl":true,"swap":true,"tmpdir":true} > > r0 = socket$alg(0x26, 0x5, 0x0) > > bind$alg(r0, &(0x7f0000000280)={0x26, 'hash\x00', 0x0, 0x0, 'sha3-256-generic\x00'}, 0x58) > > r1 = accept4(r0, 0x0, 0x0, 0x0) > > recvmmsg$unix(r1, &(0x7f0000003700)=[{{0x0, 0x700, 0x0}}], 0x600, 0x0, 0x0) > > sendmsg$can_bcm(r1, &(0x7f0000000180)={0x0, 0x0, &(0x7f0000000140)={0x0}}, 0x400c800) > > > > (0x26 is 38, or AF_ALG) > > > > From looking at the stack trace, it looks like this is triggering a > > coredump, which presumably is the ext4 write that triggers the GPF in > > ext4_put_io_end_defer. But given that the syz and C reproducer isn't > > doing anything ext4 related at all, and it's purely trying to use the > > AF_ALG socket to calculate SHA3 in the kernel (and the greek chorus > > cries out, "WHY?"[1]), I'm going to send this over to the crypto folks to > > investigate. > > Just a couple weeks ago, commit c662b043cdca ("crypto: af_alg/hash: Support > MSG_SPLICE_PAGES") had many syzbot reports against it. This particular report > is against next-20230616 which didn't include the fix commit b6d972f68983 > ("crypto: af_alg/hash: Fix recvmsg() after sendmsg(MSG_MORE)"). So there's a > high chance this report is no longer valid. I'll go ahead and invalidate it: > > #syz invalid > > > > > Cheers, > > > > - Ted > > > > [1] TIL that AF_ALG exists. Inquiring minds want to know: > > * Why do we expose the AF_ALG userspace interface? > > * Who uses it? > > * Why do they use it? > > * Is there a CONFIG option to disable it in the name of decreasing > > the attack surface of the kernel? > > * If not, should we add one? :-) > > AF_ALG has existed since 2010. My understanding that its original purpose was > to expose hardware crypto accelerators to userspace. Unfortunately, support for > exposing *any* crypto algorithm was included as well, which IMO was a mistake. > > There are quite a few different userspace programs that use AF_ALG purely to get > at the CPU-based algorithm implementations, without any sort of intention to use > hardware crypto accelerator. Probably because it seemed "easy". Or "better" > because everything in the kernel is better, right? > > It's controlled by the CONFIG_CRYPTO_USER_API_* options, with the hash support > in particular controlled by CONFIG_CRYPTO_USER_API_HASH. Though good luck > disabling it on most systems, as systemd depends on it... > Actually it turns out systemd has finally seen the light: https://github.com/systemd/systemd/commit/2c3794f4228162c9bfd9e10886590d9f5b1920d7 - Eric ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer 2023-06-30 7:46 ` Eric Biggers @ 2023-06-30 17:13 ` Theodore Ts'o 0 siblings, 0 replies; 5+ messages in thread From: Theodore Ts'o @ 2023-06-30 17:13 UTC (permalink / raw) To: Eric Biggers Cc: syzbot, adilger.kernel, linux-ext4, linux-fsdevel, linux-kernel, linux-crypto, syzkaller-bugs, David Howells On Fri, Jun 30, 2023 at 12:46:14AM -0700, Eric Biggers wrote: > > AF_ALG has existed since 2010. My understanding that its original purpose was > > to expose hardware crypto accelerators to userspace. Unfortunately, support for > > exposing *any* crypto algorithm was included as well, which IMO was a mistake. +1000.... > > There are quite a few different userspace programs that use AF_ALG purely to get > > at the CPU-based algorithm implementations, without any sort of intention to use > > hardware crypto accelerator. Probably because it seemed "easy". Or "better" > > because everything in the kernel is better, right? Do we know if any to standard crypto libraries are using AF_ALG? All aside from whether it's a good idea for userspace programs to be using kernel code because "everything is better in the kernel", I'm wondering how solicitous we should be for programs who are very likely rolling their own crypto, as opposed to using crypto library that has been written and vetted and tested for vulnerability by experts... > > It's controlled by the CONFIG_CRYPTO_USER_API_* options, with the hash support > > in particular controlled by CONFIG_CRYPTO_USER_API_HASH. Though good luck > > disabling it on most systems, as systemd depends on it... > > > > Actually it turns out systemd has finally seen the light: > https://github.com/systemd/systemd/commit/2c3794f4228162c9bfd9e10886590d9f5b1920d7 Aside from those PCI-attached crypto accelerators where you have to go through the kernel (although my experience has been that most of the time, the overhead for key scheduling, etc., is such that unless you're doing bulk crypto on large chunks of data, using external crypto hardware acclerators no longer makes sense 99.99% of the time in the 21st century), I wonder if we should consider having the kernel print a warning, "WARNING: [comm] is using AF_ALG; please consider using a real crypto library instead of rolling your own crypto". (Only half kidding.) - Ted ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-06-30 17:14 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-06-25 2:21 [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer syzbot 2023-06-29 3:57 ` Theodore Ts'o 2023-06-30 7:41 ` Eric Biggers 2023-06-30 7:46 ` Eric Biggers 2023-06-30 17:13 ` Theodore Ts'o
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).