Re: [syzbot] [efi?] [fs?] possible deadlock in efivarfs_actor

Ard Biesheuvel
2025-03-10T18:24:56Z

On Mon, 10 Mar 2025 at 19:21, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 10 Mar 2025 at 17:50, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > On Sat, 2025-03-08 at 18:52 -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: e056da87c780 Merge remote-tracking branch 'will/for-
> > > next/p..
> > > git tree:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-
> > > kernelci
> > > console output:
> > > https://syzkaller.appspot.com/x/log.txt?x=14ce9c64580000
> > > kernel config:
> > > https://syzkaller.appspot.com/x/.config?x=d6b7e15dc5b5e776
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=019072ad24ab1d948228
> > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for
> > > Debian) 2.40
> > > userspace arch: arm64
> > > syz repro:
> > > https://syzkaller.appspot.com/x/repro.syz?x=111ed7a0580000
> > > C reproducer:
> > > https://syzkaller.appspot.com/x/repro.c?x=13b97c64580000
> > >
> > > Downloadable assets:
> > > disk image:
> > > https://storage.googleapis.com/syzbot-assets/3d8b1b7cc4c0/disk-e056da87.raw.xz
> > > vmlinux:
> > > https://storage.googleapis.com/syzbot-assets/b84c04cff235/vmlinux-e056da87.xz
> > > kernel image:
> > > https://storage.googleapis.com/syzbot-assets/2ae4d0525881/Image-e056da87.gz.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the
> > > commit:
> > > Reported-by: syzbot+019072ad24ab1d948228@syzkaller.appspotmail.com
> > >
> > > efivarfs: resyncing variable state
> > > ============================================
> > > WARNING: possible recursive locking detected
> > > 6.14.0-rc4-syzkaller-ge056da87c780 #0 Not tainted
> > > --------------------------------------------
> > > syz-executor772/6443 is trying to acquire lock:
> > > ffff0000c6826558 (&sb->s_type->i_mutex_key#16){++++}-{4:4}, at:
> > > inode_lock include/linux/fs.h:877 [inline]
> > > ffff0000c6826558 (&sb->s_type->i_mutex_key#16):4}, at:
> > > iterate_dir+0x3b4/0x5f4 fs/readdir.c:101
> > >
> > > other info that might help us debug this:
> > > Possible unsafe locking scenario:
> > >
> > > CPU0
> > > ----
> > > lock(&sb->s_type->i_mutex_key#16);
> > > lock(&sb->s_type->i_mutex_key#16);
> > >
> > > *** DEADLOCK ***
> >
> > I can't figure out how you got here. the shared lock in readdir.c is
> > on the directory and the inode_lock in the actor is on the files within
> > the directory. The only way to get those to be the same is if the
> > actor gets called on the '.' element, which efivarfs_pm_notify is
> > supposed to skip with the
> >
> > file->f_pos = 2; /* skip . and .. */
> >
> > line. Emitting the '.' and '..' in positions 0 and 1 is hard coded
> > into libfs.c:dcache_readdir() unless you're also applying a patch that
> > alters that behaviour?
> >
>
> The repro log also has
>
> program crashed: BUG: unable to handle kernel paging request in
> efivarfs_pm_notify
>
> preceding the other log output regarding the locks, so the deadlock
> might be a symptom of another problem.

And one of the other logs has

[ 47.650966][ T6617] syz.2.9/6617 is trying to acquire lock:
[ 47.652339][ T6617] ffff0000d69f6558
(&sb->s_type->i_mutex_key#25){++++}-{4:4}, at:
efivarfs_actor+0x1b8/0x2b8
[ 47.654943][ T6617]
[ 47.654943][ T6617] but task is already holding lock:
[ 47.656931][ T6617] ffff0000f5b84558
(&sb->s_type->i_mutex_key#25){++++}-{4:4}, at: iterate_dir+0x3b4/0x5f4

where the locks have the same name but the address is different.

So there is something dodgy going on here, and I'm inclined to just ignore it.