netdev - Re: [Bug 8013] New: select for write hangs on a socket after write returned ECONNRESET

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:	Thu, 22 Feb 2007 06:08:05 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	johnpol@....mipt.ru
Cc:	shemminger@...ux-foundation.org, netdev@...r.kernel.org
Subject: Re: [Bug 8013] New: select for write hangs on a socket after write
 returned ECONNRESET

From: Evgeniy Polyakov <johnpol@....mipt.ru>
Date: Thu, 22 Feb 2007 16:46:21 +0300

> On Thu, Feb 22, 2007 at 05:31:38AM -0800, David Miller (davem@...emloft.net) wrote:
> > TCP_CLOSE is where we end up on a non-error close too, this has
> > the same kind of bug as your previous attempt to set POLLERR
> > here.
> > 
> > One side gets TCP_TIMEWAIT the other goes straight to TCP_CLOSE.
> > 
> > It really is not possible to change current semantics, they are the
> > best possible unfortunately.
> 
> AS a last attempt - we can have a sockt flag set when sk-err is
> installed in tcp_reset(), and tcp_poll() will set POLLERR if that flag
> exist (just like it checks for sk_err, which is cleared in tcp_sendmsg()
> when error is being returned).

Oh is that the problem?  Someone sees a fatal connection error from
write() then attempts to poll() the socket?

That is illegal.

Socket is dead, you cannot do anything reasonable with it and you know
the socket is errored so there is nothing you can possibly try to
poll() on it for.

One should close() the file descriptor at this point.  Even
getpeername() cannot work at this point, since socket is closed and
has lost identity.

Socket errors are delivered as unique events, once error is delivered
the socket is not in error state any more, it is instead closed.
That's why we clear sk->sk_err after error delivery.

BTW, there was a query about this back in Feb. 2006 on linux-kernel,
nobody replied, he reposted to linux-net in September 2006 and this
is likely where this kernel bugzilla comes from :-)

This is not a kernel bug, let's close this and move on.
-
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