netdev - Re: TCP: orphans broken by RFC 2525 #2.17

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] [day] [month] [year] [list]

Date:	Tue, 28 Sep 2010 11:26:52 +0200
From:	Willy Tarreau <w@....eu>
To:	Julian Anastasov <ja@....bg>
Cc:	netdev@...r.kernel.org
Subject: Re: TCP: orphans broken by RFC 2525 #2.17

Hello Julian,

On Tue, Sep 28, 2010 at 12:01:42PM +0300, Julian Anastasov wrote:
> 	I think for another option but I don't know the TCP details
> well:
> 
> - If SO_RCVBUF=0 really closes RX window

I've been wondering what happens to an incoming data after the RX window
is closed. Is the packet just dropped or may it still be queued. In fact,
my concerns are : if SO_RCVBUF=0 just advertises a zero window, we can
only be sure about the flush after an RTT. However, if it really prevents
the receive side from accepting new data, then I agree we're safe.

> and
> 
> - while (read() > 0) {} gets all unread data

During my tests on other products, I found that squid does that without
the zero window, possibly resulting in an infinite loop when the sender
is faster than the receiver. In our case, if the zero window works, it
should not be an issue.

> - just call close() to convert socket to orphan without a risk
> of RST
> 
> 	Now when we are orphan socket I'm not sure what has
> priority:
> 
> - if new DATA is flying to us, is it considered out of window,
> do we send RST in FIN_WAIT1/CLOSING/LAST_ACK state in this case?
> If we do not send RST then our goal is achieved: send everything
> reliably without accepting data that needs RST. And we do not
> need to keep fd in user space.

>From what I have observed, the issue is only for data present before
the close. Upon FIN_WAIT1/CLOSING/LAST_ACK, we get the expected reset
once the ACK acknowledges the last data sent, but I've not observed
it for new data.

Best regards,
Willy

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