Messages in this thread | | | From | Dmitry Vyukov <> | Date | Thu, 11 Mar 2021 18:57:48 +0100 | Subject | Re: arm64 syzbot instances |
| |
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?
| |