Re: arm64 syzbot instances

From: Arnd Bergmann <arnd@arndb.de>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 syzkaller <syzkaller@googlegroups.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: arm64 syzbot instances
Date: Thu, 11 Mar 2021 14:30:01 +0100	[thread overview]
Message-ID: <CAK8P3a1xBt6ucpVMhQrw4fGiLDZaJZ4_kn+qy9xAuykRRih6FA@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+beyZ7rjmy7im0KdSU-Pcqd4Rud3xsxonBbYVk0wU-B9g@mail.gmail.com>

On Thu, Mar 11, 2021 at 12:38 PM Dmitry Vyukov <dvyukov@google.com> 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.

> https://syzkaller.appspot.com/bug?id=b75386f45318ec181b7f49260d619fac9877d456

A freed entry on the timer list caused a bug when adding another entry.

The allocation from alloc_fdtable does not seem to be the one at fault,
as the fdtable does not contain a timer. Several of the linked kasan reports
point to ext4_fill_super() as the code that allocated and freed the timer
list entry, so it's possible that this is the same timer that later fails to
be inserted if we ever get to kfree(sbi) without killing the timer first.

I don't see how that could happen, but the code was recently rewritten
in c92dc856848f ("ext4: defer saving error info from atomic context")

> https://syzkaller.appspot.com/bug?id=5a1bc29bca656159f95c7c8bb30e3776ca860332

I see that reiserfs_xattr_jcreate_nblocks() is dereferencing a NULL
inode pointer -- inode->i_sb has offset 0x30. However, that doesn't
make any sense with the call chain, as the pointer was newly allocated
and checked for NULL.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel