OnHeadersReceived() ignored the return value of
SpdyHeadersToHttpResponse(); on a malformed CONNECT response the
response_ headers stayed null and DoReadReplyComplete() dereferenced
them.
Guard response_.headers in DoReadReplyComplete() and fail the tunnel
with ERR_TUNNEL_CONNECTION_FAILED. Both the normal CONNECT path and
the Fast Open path funnel through DoReadReplyComplete(), so a single
null check covers both, and OnHeadersReceived() stays unchanged from
upstream.
Closes audit finding F2 (SPDY OnHeadersReceived null dereference).
(cherry picked from commit afce211960e3ec092aa5347bbe6b9e2d63691d34)
When naive DoAccept failed on ERR_INSUFFICIENT_RESOURCES, rv is passed
to DoAcceptComplete, if rv is not OK, this function sets next state to
DoAccept again, when naive reaches system wide file discriptor limits,
and a pending CONNECT in queue, naive will be trapped in an infinite
busy spinning loop and can not recover as resources are not reclaimed.
Musl 1.2.3 and before call malloc() in pthread_atfork(),
which may result in a deadlock:
PartitionRoot::EnableThreadCacheIfSupported()
::partition_alloc::internal::ScopedGuard guard{lock_};
ThreadCache::Create(this);
ThreadCache::ThreadCache()
PlatformThread::CurrentId()
InitAtFork::InitAtFork()
pthread_atfork()
malloc()
ShimMalloc()
PartitionAllocFunctionsInternal::Malloc()
PartitionRoot::AllocInternal()
PartitionRoot::AllocInternalNoHooks()
PartitionRoot::RawAlloc()
::partition_alloc::internal::ScopedGuard guard{internal::PartitionRootLock(this)};
Clang reports:
floating point ABI '-mdouble-float' is incompatible with target floating point ABI '-msoft-float'
when -msoft-float is enabled for the architecture.
SpdyProxyClientSocket uses read_callback_ for both Connect() and
Read(), and its OnIOComplete() calls read_callback_, thus its fast
connect code checks read_callback_. The code was ported to
QuicProxyClientSocket without much change.
But QuicProxyClientSocket uses a separate connect_callback_ apart from
read_callback_, and its OnIOComplete() calls connect_callback_, thus
when headers are received after Connect() it doesn't need to check
read_callback_ and should always avoid calling connect_callback_.
Clients sending too many RST_STREAM is an irregular behavior.
Hack in a preceding END_STREAM DATA frame padded towards [48, 72]
before RST_STREAM so that the TLS record looks like a HEADERS frame.
The server often replies to this with a WINDOW_UPDATE because padding
is accounted in flow control. Whether this constitudes a new irregular
behavior is still unclear.
SpdyProxyClientSocket waits for 200 OK before returning OK for Connect.
Change that behavior to returning OK immediately after CONNECT header.
This feature is enabled by a "fastopen" header via the proxy delegate.
Design notes:
The current approach is better than the obvious TCP Fast Open style fake
Connect().
Fast Open should not be used for preconnects as preconnects need actual
connections set up. The Naive client does not use preconnects per se
(using "...RawConnect") but the user agent will use preconnects and the
Naive client has to infer that. Hence there is a need to check the
incoming socket for available bytes right before Connect() and configure
whether a socket should be connected with Fast Open. But fake Connect()
make it difficult to check the incoming socket because it immediately
returns and there is not enough time for the first read of the incoming
socket to arrive.
To check for preconnects it is best to push the first read of the
incoming socket to as late as possible. The other (wrong) way of doing
that is to pass in an early read callback and call it immediately after
sending HEADERS and then send the available bytes right there. This way
is wrong because it does not work with late binding, which assumes
Connect() is idempotent and causes sockets opened in this way to be
potentially bound to the wrong socket requests.
The current approach is to return OK in Connect() right after sending
HEADERS before getting the reply, which is to be received later. If the
reply is received during a subsequent Read() and the reply indicates an
error, the error is returned to the callback of the Read(); otherwise
the error is ignored with the connection disconnected and subsequent
Read() and Write() should discover the disconnection.
Per RFC 7540#6.4:
However, after sending the RST_STREAM, the sending endpoint MUST be
prepared to receive and process additional frames sent on the stream
that might have been sent by the peer prior to the arrival of the
RST_STREAM.
Lin
Zgrams
klzgrad