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: <171374175513.12877.8993642908082014881@noble.neil.brown.name>
Date: Mon, 22 Apr 2024 09:22:35 +1000
From: "NeilBrown" <neilb@...e.de>
To: "Lex Siegel" <usiegl00@...il.com>
Cc: "Chuck Lever" <chuck.lever@...cle.com>, "Jeff Layton" <jlayton@...nel.org>,
 "Olga Kornievskaia" <kolga@...app.com>, "Dai Ngo" <Dai.Ngo@...cle.com>,
 "Tom Talpey" <tom@...pey.com>,
 "Trond Myklebust" <trond.myklebust@...merspace.com>,
 "Anna Schumaker" <anna@...nel.org>, "David S. Miller" <davem@...emloft.net>,
 "Eric Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>,
 "Paolo Abeni" <pabeni@...hat.com>, linux-nfs@...r.kernel.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH] xprtsock: Fix a loop in xs_tcp_setup_socket()

On Sat, 20 Apr 2024, Lex Siegel wrote:
> When using a bpf on kernel_connect(), the call can return -EPERM.
> This causes xs_tcp_setup_socket() to loop forever, filling up the
> syslog and causing the kernel to freeze up.
> 
> Signed-off-by: Lex Siegel <usiegl00@...il.com>
> ---
>  net/sunrpc/xprtsock.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> index bb9b747d58a1..47b254806a08 100644
> --- a/net/sunrpc/xprtsock.c
> +++ b/net/sunrpc/xprtsock.c
> @@ -2446,6 +2446,8 @@ static void xs_tcp_setup_socket(struct work_struct *work)
>  		/* Happens, for instance, if the user specified a link
>  		 * local IPv6 address without a scope-id.
>  		 */
> +	case -EPERM:
> +		/* Happens, for instance, if a bpf is preventing the connect */

This will propagate -EPERM up into other layers which might not be ready
to handle it.
It might be safer to map EPERM to an error we would be more likely to
expect  from the network system - such as ECONNREFUSED or ENETDOWN.

Better still would be for kernel_connect() to return a more normal error
code - not EPERM.  If that cannot be achieved, then I think it would be
best for the sunrpc code to map EPERM to something else at the place
where kernel_connect() is called - catch it early.

NeilBrown


>  	case -ECONNREFUSED:
>  	case -ECONNRESET:
>  	case -ENETDOWN:
> -- 
> 2.39.3
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ