Re: arm64 syzbot instances

[Arnd Bergmann]

On Thu, Mar 11, 2021 at 6:57 PM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> On Thu, Mar 11, 2021 at 2:30 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > >
> > > The instances found few arm64-specific issues that we have not
> > > observed on other instances:
> >
> > I've had a brief look at these:
> >
> > > https://syzkaller.appspot.com/bug?id=1d22a2cc3521d5cf6b41bd6b825793c2015f861f
> >
> > This one  doesn't seem arm64 specific at all. While the KASAN report has shown
> > up on arm64, the link to
> > https://syzkaller.appspot.com/bug?id=aa8808729c0a3540e6a29f0d45394665caf79dca
> > seems to be for x86 machines running into the same problem.
> >
> > Looking deeper into the log, I see that fw_load_sysfs_fallback() finds
> > an existing
> > list entry on the global "pending_fw_head" list, which seems to have been freed
> > earlier (the allocation listed here is not for a firmware load, so presumably it
> > was recycled in the meantime). The log shows that this is the second time that
> > loading the regulatory database failed in that run, so my guess is that it was
> > the first failed load that left the freed firmware private data on the
> > list, but I
> > don't see how that happened.
> >
> > > https://syzkaller.appspot.com/bug?id=bb2c16b0e13b4de4bbf22cf6a4b9b16fb0c20eea
> >
> > This one rings a bell: opening a 8250 uart on a well-known port must fail
> > when no I/O ports are registered in the system, or when the PCI I/O ports
> > are mapped to an invalid area.
> >
> > It seems to be attempting a register access at I/O port '1' (virtual
> > address 0xfffffbfffe800001 is one byte into the well-known PCI_IOBASE),
> > which is an unusual place for a UART, traditional PCs had it at 0x3F8.
> >
> > This could be either a result of qemu claiming to support a PIO based UART
> > at the first available address, or the table of UARTS being uninitialized
> > .bss memory.
> >
> > Definitely an arm64 specific bug.
>
> I can reproduce this with just:
>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <sys/types.h>
> #include <unistd.h>
>
> int main(void)
> {
>   int fd = syscall(__NR_openat, 0xffffffffffffff9cul, "/dev/ttyS3", 0ul, 0ul);
>   char ch = 0;
>   syscall(__NR_ioctl, fd, 0x5412, &ch); // TIOCSTI
>   return 0;
> }
>
>
> It does not even do any tty setup... does it point to a qemu bug?

There are at least two bugs here, but both could be either in the
kernel or in qemu:

a) accessing a legacy ISA/LPC port should not result in an oops,
    but should instead return values with all bits set. There could
    be a ratelimited console warning about broken drivers, but we
    can't assume that all drivers work correctly, as some ancient
    PC style drivers still rely on this.
    John Garry has recently worked on a related bugfix, so maybe
    either this is the same bug he encountered (and hasn't merged
    yet), or if his fix got merged there is still a remaining problem.

b) It should not be possible to open /dev/ttyS3 if the device is
    not initialized. What is the output of 'cat /proc/tty/driver/serial'
    on this machine? Do you see any messages from the serial
    driver in the boot log?
    Unfortunately there are so many different ways to probe devices
    in the 8250 driver that I don't know where this comes from.
    Your config file has
   CONFIG_SERIAL_8250_PNP=y
   CONFIG_SERIAL_8250_NR_UARTS=32
   CONFIG_SERIAL_8250_RUNTIME_UARTS=4
   CONFIG_SERIAL_8250_EXTENDED=y
   I guess it's probably the preconfigured uarts that somehow
   become probed without initialization, but it could also be
   an explicit device incorrectly described by qemu.

        Arnd