Messages in this thread | | | From | Dmitry Vyukov <> | Date | Fri, 12 Mar 2021 09:46:03 +0100 | Subject | Re: arm64 syzbot instances |
| |
On Fri, Mar 12, 2021 at 9:40 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Mar 11, 2021 at 6:57 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Thu, Mar 11, 2021 at 2:30 PM Arnd Bergmann <arnd@arndb.de> 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.
Here is fool boot log, /proc/tty/driver/serial and the crash: https://gist.githubusercontent.com/dvyukov/084890d9b4aa7cd54f468e652a9b5881/raw/54c12248ff6a4885ba6c530d56b3adad59bc6187/gistfile1.txt
| |