linux-kernel - Re: [syzbot] [efi?] [fs?] possible deadlock in efivarfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXEfG=Q3pk6PsVZxf5qCjEBTwTjUCJcNwBPO3PqNmSp=hw@mail.gmail.com>
Date: Mon, 10 Mar 2025 19:24:43 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: syzbot <syzbot+019072ad24ab1d948228@...kaller.appspotmail.com>, jk@...abs.org, 
	linux-efi@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [efi?] [fs?] possible deadlock in efivarfs_actor

On Mon, 10 Mar 2025 at 19:21, Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Mon, 10 Mar 2025 at 17:50, James Bottomley
> <James.Bottomley@...senpartnership.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@...kaller.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.