|
From: Dmitry V. <dv...@go...> - 2022-10-06 07:31:44
|
On Wed, 5 Oct 2022 at 17:57, Dmitry Vyukov <dv...@go...> wrote: > > On Wed, 5 Oct 2022 at 16:01, Tetsuo Handa > <pen...@i-...> wrote: > > > > I suspect that there is a bug in backtrace decoder for arm64. > > > > > _atomic_dec_and_lock+0xc8/0x130 lib/dec_and_lock.c:28 > > > iput+0x50/0x324 fs/inode.c:1766 > > > ntfs_fill_super+0x1254/0x14a4 fs/ntfs/super.c:188 > > > > Both ntfs and ntfs3 provide ntfs_fill_super() and > > > > > get_tree_bdev+0x1e8/0x2a0 fs/super.c:1323 > > > ntfs_fs_get_tree+0x28/0x38 fs/ntfs3/super.c:1358 > > > > ntfs_fs_get_tree() in fs/ntfs3/super.c is passing > > ntfs_fill_super() defined in fs/ntfs3/super.c . > > > > Therefore, I believe that > > > > ntfs_fill_super+0x1254/0x14a4 > > > > should be somewhere in fs/ntfs3/super.c file. > > > > > vfs_get_tree+0x40/0x140 fs/super.c:1530 > > > do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 > > > > Similar problem "WARNING: nested lock was not taken in ntfs_fill_super" > > at https://syzkaller.appspot.com/bug?id=163e6da17e1a91995f563a2d5ee68a65468fb713 > > looks reasonable. > > Interesting. > > We have logic to select the right symbols based on size: > https://github.com/google/syzkaller/blob/2c6543adc4c5a9108455d1e59b0df0d4afc05c99/pkg/report/linux.go#L427 > > However, in this case this piece does not work: > https://github.com/google/syzkaller/blob/2c6543adc4c5a9108455d1e59b0df0d4afc05c99/pkg/symbolizer/nm.go#L50-L56 > > It worked for x86, but not for arm64. > > In this case the symbols are: > > $ nm -nS ./vmlinux-bbed346d | grep -C 3 ntfs_fill_super > ffff800008bb6b80 t $x.94 > ffff800008bb6b84 t $x.4 > ffff800008bb6b84 0000000000000058 t ntfs_mount > ffff800008bb6bdc 0000000000001030 t ntfs_fill_super > ffff800008bb6ca0 t $x.6 > ffff800008bb7c00 t $x.9 > ffff800008bb7c08 t $x.11 > -- > ffff800008c03ae0 0000000000000038 t ntfs_fs_get_tree > ffff800008c03b18 00000000000001f4 t ntfs_fs_reconfigure > ffff800008c03d0c 000000000000013c t put_ntfs > ffff800008c03e48 00000000000014a4 t ntfs_fill_super > ffff800008c052e0 t $x.12 > ffff800008c052e8 t $x.14 > ffff800008c052ec 000000000000008c t ntfs_map_page > > and these $x things break our calculations. > > I see that the kernel indeed calculates the size based on the start of > the next symbol: > https://elixir.bootlin.com/linux/latest/source/kernel/kallsyms.c#L288 > > I think we need to do the same in pkg/nm to match the kernel logic. > > P.s. the provided vmlinux was very useful in this case. Should be fixed by: https://github.com/google/syzkaller/pull/3424 |
