linux-kernel - Re: [syzbot] [ntfs3?] INFO: task hung in __start

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251125-hausdach-antrag-f3e4bcd35365@brauner>
Date: Tue, 25 Nov 2025 10:35:13 +0100
From: Christian Brauner <brauner@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: neil@...wn.name, agruenba@...hat.com, 
	almaz.alexandrovich@...agon-software.com, dhowells@...hat.com, gfs2@...ts.linux.dev, jack@...e.cz, 
	linux-afs@...ts.infradead.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	marc.dionne@...istor.com, ntfs3@...ts.linux.dev, syzkaller-bugs@...glegroups.com, 
	viro@...iv.linux.org.uk, syzbot+2fefb910d2c20c0698d8@...kaller.appspotmail.com
Subject: Re: [syzbot] [ntfs3?] INFO: task hung in __start_renaming

On Mon, Nov 24, 2025 at 10:21:07AM +0100, Mateusz Guzik wrote:
> On Mon, Nov 24, 2025 at 10:01:53AM +0100, Mateusz Guzik wrote:
> > sigh, so it *is* my patch, based on syzbot testing specifically on
> > directory locking vs inode branches, but I don't see why.
> > 
> > I take it the open() codepath took the rwsem, hence the rename is
> > sleeping. Given that all reproducers find it *on* cpu, it may be this
> > is busy looping for some reason.
> > 
> > I don't have time to dig more into it right now, so I think it would
> > be best to *drop* my patch for the time being. Once I figure it out
> > I'll send a v2.
> > 
> 
> good news, now that I gave up I found it.
> 
> insert_inode_locked() is looping indefinitely an inode which is no
> longer I_NEW or I_CREATING.
> 
> In stock kernel:
>                 if (unlikely(!inode_unhashed(old))) {
>                         iput(old);
>                         return -EBUSY;
>                 }
>                 iput(old);
> 
> it returns an error
> 
> with my patch:
>                if (isnew) {
>                         wait_on_new_inode(old);
>                         if (unlikely(!inode_unhashed(old))) {
>                                 iput(old);
>                                 return -EBUSY;
>                         }
>                 }
>                 iput(old);
> 
> unhashed status is only ever check if I_NEW was spotted,
> 
> which can be false. Afterwards the routine is stuck in endless cycle of
> finding the inode and iputting it.
> 
> Christian, I think the easiest way out is to add the fix I initially
> posted, inlined below. It *was* successfuly tested by syzbot. It retains
> inode_unhashed checks even when they are not necessary to avoid any more
> surprises.

Thanks for tracking this down. Now folded.