Re: kernel BUG at net/rxrpc/local_object.c:LINE!

Dmitry Vyukov
2019-07-05T12:13:03Z

,On Tue, Jul 2, 2019 at 3:37 PM David Howells <dhowells@redhat.com> wrote:
>
> syzbot <syzbot+1e0edc4b8b7494c28450@syzkaller.appspotmail.com> wrote:
>
> I *think* the reproducer boils down to the attached, but I can't get syzkaller
> to work and the attached sample does not cause the oops to occur. Can you try
> it in your environment?
>
> > The bug was bisected to:
> >
> > commit 46894a13599a977ac35411b536fb3e0b2feefa95
> > Author: David Howells <dhowells@redhat.com>
> > Date: Thu Oct 4 08:32:28 2018 +0000
> >
> > rxrpc: Use IPv4 addresses throught the IPv6
>
> This might not be the correct bisection point. If you look at the attached
> sample, you're mixing AF_INET and AF_INET6. If you try AF_INET throughout,
> that might get a different point. On the other hand, since you've bound the
> socket, the AF_INET6 passed to socket() should be ignored.
>
> David
> ---
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <arpa/inet.h>
> #include <linux/rxrpc.h>
>
> static const unsigned char inet4_addr[4] = {
> 0xe0, 0x00, 0x00, 0x01
> };
>
> int main(void)
> {
> struct sockaddr_rxrpc srx;
> int fd;
>
> memset(&srx, 0, sizeof(srx));
> srx.srx_family = AF_RXRPC;
> srx.srx_service = 0;
> srx.transport_type = AF_INET;
> srx.transport_len = sizeof(srx.transport.sin);
> srx.transport.sin.sin_family = AF_INET;
> srx.transport.sin.sin_port = htons(0x4e21);
> memcpy(&srx.transport.sin.sin_addr, inet4_addr, 4);
>
> fd = socket(AF_RXRPC, SOCK_DGRAM, AF_INET6);
> if (fd == -1) {
> perror("socket");
> exit(1);
> }
>
> if (bind(fd, (struct sockaddr *)&srx, sizeof(srx)) == -1) {
> perror("bind");
> exit(1);
> }
>
> sleep(20);
>
> // Whilst sleeping, hit with:
> // echo -e '\0\0\0\0\0\0\0\0' | ncat -4u --send-only 224.0.0.1 20001
>
> return 0;
> }

Hi David,

I can't re-reproduce it locally in qemu either. Though, syzbot managed
to re-reproduce it reliably during bisection (maybe there is some
difference in hardware and as the result the injected ethernet packet
would need some different values). Let's try to ask it again to make
sure:
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master

Re bisection, I don't know if there are some more subtle things as
play (you are in the better position to judge that), but bisection log
looks good, it tracked the target crash throughout and wasn't
distracted by any unrelated bugs, etc. So I don't see any obvious
reasons to not trust it.