netdev - Re: [RFC PATCH] accounting for socket backlog

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:	Fri, 26 Feb 2010 14:12:25 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Zhu Yi <yi.zhu@...el.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Shi, Alex" <alex.shi@...el.com>
Subject: Re: [RFC PATCH] accounting for socket backlog

Le vendredi 26 février 2010 à 10:34 +0800, Zhu Yi a écrit :
> On Thu, 2010-02-25 at 19:24 +0800, Eric Dumazet wrote:
> > - What about other protocols that also use a backlog ?
> 
> I don't think protocols with flow/congestion control capability have
> such issue. We have tested TCP is immune. Other current backlog users
> are dccp, sctp, tipc, x.25 and llc. We didn't test all of them. But
> looks like only llc here is possible but unlikely?
> 

I looked again for TCP case and I see same problem than UDP. If socket
is locked by user, and a softirq flood happens, you can fill backlog too
with frames (any frame with correct tuple, even with bad sequences), and
exhaust memory.


> > - __release_sock() could run forever with no preemption, even with a
> > limit on backlog. 
> 
> Yes, but there is no critical impact like memory exhausted for this
> case.
> 

Well, if you have one processor, and a process doesnt want to yield the
cpu (apart of sofirq of course that is filling the backlog while your
process tries to empty it), your machine is dead. This is critical
too :)



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