netdev - Re: [PATCH] tipc: flow control should not account for sk

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: <1349342493.16011.32.camel@edumazet-glaptop>
Date:	Thu, 04 Oct 2012 11:21:33 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	erik.hugne@...csson.com
Cc:	netdev@...r.kernel.org, jon.maloy@...csson.com,
	ying.xue@...driver.com, paul.gortmaker@...driver.com
Subject: Re: [PATCH] tipc: flow control should not account for sk_rcvbuf

On Thu, 2012-10-04 at 11:14 +0200, erik.hugne@...csson.com wrote:
> From: Erik Hugne <erik.hugne@...csson.com>
> 
> The TIPC flow control is design around message count, and it should not
> account for the sk_rcvbuf when enqueueing messages to the socket
> receive queue.
> 
> This fixes a problem when the sk_add_backlog fails due to this check
> and TIPC_ERR_OVERLOAD is reported back to the sender.
> The sender would then drop it's side of the connection only, leaving
> a stale connection on the other end.
> 
> Signed-off-by: Erik Hugne <erik.hugne@...csson.com>
> ---
>  net/tipc/socket.c |    6 ++----
>  1 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/net/tipc/socket.c b/net/tipc/socket.c
> index 09dc5b9..02fed90 100644
> --- a/net/tipc/socket.c
> +++ b/net/tipc/socket.c
> @@ -1269,10 +1269,8 @@ static u32 dispatch(struct tipc_port *tport, struct sk_buff *buf)
>  	if (!sock_owned_by_user(sk)) {
>  		res = filter_rcv(sk, buf);
>  	} else {
> -		if (sk_add_backlog(sk, buf, sk->sk_rcvbuf))
> -			res = TIPC_ERR_OVERLOAD;
> -		else
> -			res = TIPC_OK;
> +		__sk_add_backlog(sk, buf);
> +		res = TIPC_OK;
>  	}
>  	bh_unlock_sock(sk);
>  


What guarantee do we have this cannot use all kernel memory ?

If sk->sk_rcvbuf is not an acceptable limit here, you must use a
different limit, but not infinity.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html