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: <8cf7d7efdc069772d69f913b02e5f67feadce18e.camel@HansenPartnership.com>
Date: Mon, 10 Mar 2025 12:50:46 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: syzbot <syzbot+019072ad24ab1d948228@...kaller.appspotmail.com>, 
	ardb@...nel.org, 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 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?

Regards,

James