Both p9_fd_create_tcp() and p9_fd_create_unix() will call
p9_socket_open(). If the creation of p9_trans_fd fails,
p9_fd_create_tcp() and p9_fd_create_unix() will return an
error directly instead of releasing the cscoket, which will
result in a socket leak.

This patch adds sock_release() to fix the leak issue.

Fixes: 6b18662e239a ("9p connect fixes")
Signed-off-by: Wang Hai <wanghai38@huawei.com>
---
 net/9p/trans_fd.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 56a186768750..f834726d21ea 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -860,8 +860,10 @@ static int p9_socket_open(struct p9_client *client, struct socket *csocket)
 	struct file *file;
 
 	p = kzalloc(sizeof(struct p9_trans_fd), GFP_KERNEL);
-	if (!p)
+	if (!p) {
+		sock_release(csocket);
 		return -ENOMEM;
+	}
 
 	csocket->sk->sk_allocation = GFP_NOIO;
 	file = sock_alloc_file(csocket, 0, NULL);
-- 
2.17.1

Hello:

This patch was applied to netdev/net.git (master)
by David S. Miller <davem@davemloft.net>:

On Thu, 24 Nov 2022 16:10:05 +0800 you wrote:
> Both p9_fd_create_tcp() and p9_fd_create_unix() will call
> p9_socket_open(). If the creation of p9_trans_fd fails,
> p9_fd_create_tcp() and p9_fd_create_unix() will return an
> error directly instead of releasing the cscoket, which will
> result in a socket leak.
> 
> This patch adds sock_release() to fix the leak issue.
> 
> [...]

Here is the summary with links:
  - [net] net/9p: Fix a potential socket leak in p9_socket_open
    https://git.kernel.org/netdev/net/c/dcc14cfd7deb

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Wang Hai wrote on Thu, Nov 24, 2022 at 04:10:05PM +0800:
> Both p9_fd_create_tcp() and p9_fd_create_unix() will call
> p9_socket_open(). If the creation of p9_trans_fd fails,
> p9_fd_create_tcp() and p9_fd_create_unix() will return an
> error directly instead of releasing the cscoket, which will

(typo, socket or csocket -- I'll fix this on applying)

> result in a socket leak.
> 
> This patch adds sock_release() to fix the leak issue.

Thanks, it looks good to me.
A bit confusing that sock_alloc_files() calls sock_release() itself on
failure, but that means this one's safe at least...

> Fixes: 6b18662e239a ("9p connect fixes")

(the leak was present before that commit so I guess that's not really
correct -- but it might help figure out up to which point stable folks
will be able to backport so I guess it's useful either way)

-- 
Dominique

On Thu, Nov 24, 2022 at 06:15:54PM +0900, asmadeus@codewreck.org wrote:
> Wang Hai wrote on Thu, Nov 24, 2022 at 04:10:05PM +0800:
> > Both p9_fd_create_tcp() and p9_fd_create_unix() will call
> > p9_socket_open(). If the creation of p9_trans_fd fails,
> > p9_fd_create_tcp() and p9_fd_create_unix() will return an
> > error directly instead of releasing the cscoket, which will
> 
> (typo, socket or csocket -- I'll fix this on applying)
> 
> > result in a socket leak.
> > 
> > This patch adds sock_release() to fix the leak issue.
> 
> Thanks, it looks good to me.
> A bit confusing that sock_alloc_files() calls sock_release() itself on
> failure, but that means this one's safe at least...

sock_alloc_file() unconditionally consumes socket reference;
either it is transferred to new struct file it returns, or
it's dropped.  Makes for simpler logics in callers...
FWIW,
ACKed-by: Al Viro <viro@zeniv.linux.org.uk>
on the leak fix.

在 2022/11/24 17:15, asmadeus@codewreck.org 写道:
> Wang Hai wrote on Thu, Nov 24, 2022 at 04:10:05PM +0800:
>> Both p9_fd_create_tcp() and p9_fd_create_unix() will call
>> p9_socket_open(). If the creation of p9_trans_fd fails,
>> p9_fd_create_tcp() and p9_fd_create_unix() will return an
>> error directly instead of releasing the cscoket, which will
> (typo, socket or csocket -- I'll fix this on applying)
Hi, Dominique.
Thanks for reviewing.

Here is a typo, it should be csocket.
>> result in a socket leak.
>>
>> This patch adds sock_release() to fix the leak issue.
> Thanks, it looks good to me.
> A bit confusing that sock_alloc_files() calls sock_release() itself on
> failure, but that means this one's safe at least...
Yes, this mechanism was introduced by commit 8e1611e23579 ("make 
sock_alloc_file() do sock_release() on failures")
>
>> Fixes: 6b18662e239a ("9p connect fixes")
> (the leak was present before that commit so I guess that's not really
> correct -- but it might help figure out up to which point stable folks
> will be able to backport so I guess it's useful either way)
Yes, there was already a leak before this patch, and this patch also 
introduces a leak

-- 
Wang Hai