netdev - RE: [PATCH net-next v2 2/8] tipc: compensate for double accounting in socket rcv buffer

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]

Date:	Wed, 14 May 2014 10:45:42 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Jon Maloy <jon.maloy@...csson.com>
Cc:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Erik Hugne <erik.hugne@...csson.com>,
	"ying.xue@...driver.com" <ying.xue@...driver.com>,
	"maloy@...jonn.com" <maloy@...jonn.com>,
	"tipc-discussion@...ts.sourceforge.net" 
	<tipc-discussion@...ts.sourceforge.net>
Subject: RE: [PATCH net-next v2 2/8] tipc: compensate for double accounting
 in socket rcv buffer

On Wed, 2014-05-14 at 12:53 +0000, Jon Maloy wrote:

> For us, the underlying problem is that sk_backlog.len does not
> give correct information about the buffer situation.  There is a comment
> in  _release_sock() trying to explain why.:
> 
> /*
>   * Doing the zeroing here guarantee we can not loop forever
>   * while a wild producer attempts to flood us.
>   */
> 
> but I fail to understand how this scenario can happen even with TCP.
> Yes, it can throw away packets, but not until the receive buffer is full,
> and then sk_add_backlog() should start rejecting new messages anyway?
> There is evidently something I have missed here.

The following can happen :

An innocent user thread does a socket system call.
It owns the socket.

Then a flood of incoming messages happen, constantly trying to push new
packets for this socket. Note the packets can be spoofed ones.

Softirq handler notices socket is owned by 'user', so queue packets into
backlog, unless the sk_rcvbuf limit is hit.

If we were releasing sk_backlog.len for every dequeued skb, we could
have a deadlock for the innocent user thread, who could never exit from
__release_sock()

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8eae939f1400326b06d0c9afe53d2a484a326871

So really you do not want to 'relax' this check.

All you need to do is have a big enough sk_rcvbuf for the expected and
reasonable amount of memory you allow to be stored in input queues for
your socket.



--
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