[syzbot] [ext4?] general protection fault in ext4_put_io_end_defer

[syzbot] [ext4?] general protection fault in ext4_put_io_end_defer

[syzbot]

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

Re: [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer

[Theodore Ts'o]

#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?  :-)

Re: [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer

[Eric Biggers]

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

Re: [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer

[Eric Biggers]

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

Re: [syzbot] [ext4?] general protection fault in ext4_put_io_end_defer

[Theodore Ts'o]

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