linux-kernel - Re: [syzbot] Re: [syzbot] [nfs?] [net?] possible deadlock in rpc_close

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250703015033.GH1880847@ZenIV>
Date: Thu, 3 Jul 2025 02:50:33 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: syzbot <syzbot+169de184e9defe7fe709@...kaller.appspotmail.com>
Cc: linux-kernel@...r.kernel.org, lizhi.xu@...driver.com
Subject: Re: [syzbot] Re: [syzbot] [nfs?] [net?] possible deadlock in
 rpc_close_pipes

On Wed, Jul 02, 2025 at 06:17:26PM -0700, syzbot wrote:
> For archival purposes, forwarding an incoming command email to
> linux-kernel@...r.kernel.org.
> 
> ***
> 
> Subject: Re: [syzbot] [nfs?] [net?] possible deadlock in rpc_close_pipes
> Author: lizhi.xu@...driver.com
> 
> #syz test
> 
> diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
> index 0bd1df2ebb47..ae5643e0bc43 100644
> --- a/net/sunrpc/rpc_pipe.c
> +++ b/net/sunrpc/rpc_pipe.c
> @@ -693,7 +693,7 @@ void
>  rpc_unlink(struct rpc_pipe *pipe)
>  {
>  	if (pipe->dentry) {
> -		simple_recursive_removal(pipe->dentry, rpc_close_pipes);
> +		locked_recursive_removal(pipe->dentry, rpc_close_pipes);
>  		pipe->dentry = NULL;
>  	}
>  }

Excuse me, but... which caller of rpc_unlink() is holding any directories locked?
IOW, this patch is an LLM-grade nonsense.  If it really *is* chatbot-generated,
that's a lovely demonstration of the reasons why generative AI have no business
sending patches of any kind.

Note that report clearly refers to rpc_close_pipes() as one of the locations
involved in a possible deadlock.  The difference between simple_recursive_removal()
and locked_recursive_removal() is that the latter is to be called when the caller
is already holding ->i_rwsem on the victim's parent.  *IF* that was the case,
the deadlock report would point to that caller vs. simple_recursive_removal().

rpc_close_pipes() is a *callback* passed to simple_recursive_removal(); if it
turned around and called rpc_unlink() we would have a serious problem indeed,
and it's very easy to see that nothing of that sort is happening.

The worst part is, that patch is likely to make lockdep STFU - by failing to
lock the parent.  You really need to reason; "throw random shit at the bot
until the warning goes away" is an actively harmful strategy.

As for the warning, it is a false positive caused by lockdep annotations, as
the original report suggested.  Replace inode_lock(inode) in rpc_close_pipes()
with inode_lock_nested(inode, I_MUTEX_CHILD) and try to reproduce that.

For syzbot maintainers - git blame is useful.  I would really appreciate the
original report...