linux-kernel - Re: [syzbot] [kernfs?] possible deadlock in kernfs_fop

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]

Date: Sun, 7 Apr 2024 01:48:16 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Hillf Danton <hdanton@...a.com>
Cc: syzbot <syzbot+9a5b0ced8b1bfb238b56@...kaller.appspotmail.com>,
	amir73il@...il.com, linux-kernel@...r.kernel.org, miklos@...redi.hu,
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [kernfs?] possible deadlock in kernfs_fop_llseek

On Sat, Apr 06, 2024 at 04:23:51PM +0800, Hillf Danton wrote:
> On Sat, 6 Apr 2024 08:11:30 +0100 Al Viro <viro@....linux.org.uk>
> > On Sat, Apr 06, 2024 at 12:05:04AM -0700, syzbot wrote:
> > > commit:         3398bf34 kernfs: annotate different lockdep class for ..
> > > git tree:       https://github.com/amir73il/linux/ vfs-fixes
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=c5cda112a8438056
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=9a5b0ced8b1bfb238b56
> > > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
c > > 
> > > Note: no patches were applied.
> > 
> > How about the same test on 6c6e47d69d821047097909288b6d7f1aafb3b9b1?
> > 
> JFYI it works [1]
> 
> [1] https://lore.kernel.org/lkml/000000000000a386f2061562ba6a@google.com/

It works on top of v6.8-8951-gfe46a7dd189e; boot failures on top
of v6.9-rc2-387-g6c6e47d69d82 and on top of v6.9-rc1.  See
https://lore.kernel.org/lkml/00000000000039026a06155b3a12@google.com/
and
https://lore.kernel.org/lkml/000000000000107743061568319c@google.com/
resp.  Both hit refcount_t underflow in virtio_scsi probing, with
very similar call chains (if not outright identical ones - hadn't
checked in details).

I don't believe that this patch introduces a boot failure, let alone
this one - all of that is likely to be shared with the corresponding
points on mainline.

Might be interesting to try and figure out what that is, but that's
a separate bug.