netdev - Re: Add a SOCK_DESTROY operation to close sockets from userspace

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1447879416.562854.443622857.62708268@webmail.messagingengine.com>
Date:	Wed, 18 Nov 2015 21:43:36 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Miller <davem@...emloft.net>, lorenzo@...gle.com
Cc:	eric.dumazet@...il.com, stephen@...workplumber.org,
	netdev@...r.kernel.org, edumazet@...gle.com, ek@...gle.com,
	maze@...gle.com, dtor@...gle.com
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Wed, Nov 18, 2015, at 21:35, David Miller wrote:
> From: Lorenzo Colitti <lorenzo@...gle.com>
> Date: Wed, 18 Nov 2015 19:47:21 +0900
> 
> > On Wed, Nov 18, 2015 at 7:19 PM, Hannes Frederic Sowa
> > <hannes@...essinduktion.org> wrote:
> >> I bet there will soon be a timewaitd which handles the not configurable
> >> (David has rejected all those patches so far) timeout of TIME_WAIT
> >> sockets. And I bet it will be used. :/
> > 
> > No, SOCK_DESTROY has no effect on TCP_TIME_WAIT sockets or any other
> > non-full socket.
> > 
> > When called on any socket where sk_fullsock(sk) is false, it returns
> > EOPNOTSUPP because there is nothing to do. Its purpose is to interrupt
> > blocked userspace socket calls, not to release resources.
> 
> +1

Basically my concern is the same one I tried to express in the other
patch about Florian's patch "[PATCH -next] net: tcp: move to timewait
when receiving data post active-close": we could give the socket back
way too early so the quadruple can be reused. If timestamps are not in
use or we are dealing with NAT were we have dozens of synchronized
clocks behind the masquerading device, we could end up in accepting
delayed data. Especially this scenario can come up when the address is
actually not released but someone uses this feature on a server.

Bye,
Hannes
--
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