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

["Theodore Ts'o" <tytso@mit.edu>]

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