New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Aug 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 135485: SPDY - Pushed stream - crash accessing https://jetty.intalio.com:10111/spdy

Reported by rtenneti@chromium.org, Jul 2 2012 Project Member

Issue description

In SPDY/2 (enabled by passing --enable-npn) accessing URL https://jetty.intalio.com:10111/spdy/ will result in a crash.

Wasn't able to reproduce the issue in SPDY/3.


void SpdyStream::PushedStreamReplayData() {
...
  int rv = delegate_->OnResponseReceived(*response_, response_time_, OK);
  if (rv == ERR_INCOMPLETE_SPDY_HEADERS) {
    // We don't have complete headers.  Assume we're waiting for another
    // HEADERS frame.  Since we don't have headers, we had better not have
    // any pending data frames.
    DCHECK_EQ(0U, pending_buffers_.size());           <==== crash
    return;
  }

------------

In M20, SPDY/2 is enabled for a very small percentage of users. Should we fix (or support) pushed streams in SPDY/2?
 

Comment 1 by rtenneti@chromium.org, Jul 2 2012

Cc: gr...@intalio.com sbor...@intalio.com

Comment 2 by rtenneti@chromium.org, Jul 2 2012

The following is the crash in my debug builds

[6456:8948:945561574:FATAL:spdy_stream.cc(108)] Check failed: 0U == pending_buffers_.size() (0 vs. 2)
Backtrace:
        base::debug::StackTrace::StackTrace [0x1006FEC1+33] (d:\src\tree1\src\base\debug\stack_trace_win.cc:149)
        logging::LogMessage::~LogMessage [0x100C967E+94] (d:\src\tree1\src\base\logging.cc:563)
        net::SpdyStream::PushedStreamReplayData [0x09142DE7+343] (d:\src\tree1\src\net\spdy\spdy_stream.cc:108)
        base::internal::RunnableAdapter<void (__thiscall net::SpdyStream::*)(void)>::Run [0x0914D5B1+33] (d:\src\tree1\src\base\bind_internal.h:132)
        base::internal::InvokeHelper<0,void,base::internal::RunnableAdapter<void (__thiscall net::SpdyStream::*)(void)>,void __cdecl(net::SpdyStream * const &)>::MakeItSo [0x0914D4BA+26] (d:\src\tree1\src\base\bind_internal.h:869)
        base::internal::Invoker<1,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall net::SpdyStream::*)(void)>,void __cdecl(net::SpdyStream *),void __cdecl(net::SpdyStream *)>,void __cdecl(net::SpdyStream *)>::Run [0x0914D2A9+73] (d:\src\tree1\src\base\bind_internal.h:1170)
        base::Callback<void __cdecl(void)>::Run [0x10059A7F+47] (d:\src\tree1\src\base\callback.h:272)
        MessageLoop::RunTask [0x100D3ECF+591] (d:\src\tree1\src\base\message_loop.cc:462)
        MessageLoop::DeferOrRunPendingTask [0x100D4154+52] (d:\src\tree1\src\base\message_loop.cc:475)
        MessageLoop::DoWork [0x100D4FF6+262] (d:\src\tree1\src\base\message_loop.cc:648)
        base::MessagePumpForIO::DoRunLoop [0x100ED7F2+50] (d:\src\tree1\src\base\message_pump_win.cc:497)
        base::MessagePumpWin::RunWithDispatcher [0x100EB4A2+130] (d:\src\tree1\src\base\message_pump_win.cc:64)
        base::MessagePumpWin::Run [0x10023E9C+28] (d:\src\tree1\src\base\message_pump_win.h:48)
        MessageLoop::RunInternal [0x100D3AB9+313] (d:\src\tree1\src\base\message_loop.cc:419)
        MessageLoop::RunHandler [0x100D380E+46] (d:\src\tree1\src\base\message_loop.cc:393)
        base::RunLoop::Run [0x10143B59+41] (d:\src\tree1\src\base\run_loop.cc:46)
        MessageLoop::Run [0x100D2A21+81] (d:\src\tree1\src\base\message_loop.cc:299)
        base::Thread::Run [0x101BE046+22] (d:\src\tree1\src\base\threading\thread.cc:134)
        base::Thread::ThreadMain [0x101BE27B+283] (d:\src\tree1\src\base\threading\thread.cc:169)
        base::`anonymous namespace'::ThreadFunc [0x1019E5CF+95] (d:\src\tree1\src\base\threading\platform_thread_win.cc:59)
        BaseThreadInitThunk [0x75593677+18]
        RtlInitializeExceptionChain [0x76F09F42+99]
        RtlInitializeExceptionChain [0x76F09F15+54]

Comment 3 by jsc...@chromium.org, Jul 2 2012

Labels: -Type-Bug Type-Security Restrict-View-SecurityTeam
Adding the security flags. According to Will this looks like a NULL deref in the browser process. That would be low-severity, but I'll wait on confirmation before completing triage.

Comment 4 by tbec...@intalio.com, Jul 3 2012

Not, that you can't reproduce it with SPDY/3 because the broken headers are sent only for SPDY/2 on the test instance I prepared. So the issue might as well be in SPDY/3.

Comment 5 by infe...@chromium.org, Jul 3 2012

Does this crash happen in release builds ?

Comment 6 by rtenneti@chromium.org, Jul 3 2012

I was able to duplicate it in stable channel with  --enable-npn and accessing  https://jetty.intalio.com:10111/spdy/ on Linux.

Comment 7 by infe...@chromium.org, Jul 3 2012

Labels: SecSeverity-Low Mstone-21

Comment 8 by willchan@chromium.org, Jul 18 2012

Back from vacation now. What's the status here?

Comment 9 Deleted

Comment 10 by rtenneti@chromium.org, Aug 1 2012

On Tue, Jun 26, 2012 at 1:49 PM, Thomas Becker <tbecker@intalio.com> wrote:
Hi William,

I've had a hard time to reproduce the chromium browser crash. Basically it seems to be a bug in our implementation of push which seems to cause chromium to crash. Problem was, that the browser does not always crash. Sometimes it just loads for a long time, sometimes it works and sometimes it crashes. I didn't know exactly what state of the server side implementation was causing the issue, nor is it always reproducible and it took me a couple of hours to reproduce it.

I "think" this is either caused by us not sending the status header on the push syn or by sending a broken url header. I'm not 100% sure which one of both is causing the crash or if it's the combination of both bugs. I also had to add a big image to make the crash occur more often. Again am not sure if the big image really has an effect. I've setup a jetty instance with the broken spdy v2 push implementation : https://jetty.intalio.com:10111/spdy/

Just reload it a few times. And watch the behavior.

Here's the broken spdy push syns:
t=1340740074058 [st=  554]    SPDY_SESSION_PUSHED_SYN_STREAM
                              --> associated_stream = 1
                              --> flags = 2
                              --> accept-encoding: gzip,deflate,sdch
                                  host: jetty.intalio.com:10111
                                  method: GET
                                  referer: https://jetty.intalio.com:10111/spdy/
                                  scheme: https
                                  url: https://jetty.intalio.com:10111/spdy/stylesheet.css
                                  version: HTTP/1.1
                                  x-spdy-push: true
                              --> id = 2

t=1340740074436 [st=  932]    SPDY_SESSION_PUSHED_SYN_STREAM
                              --> associated_stream = 1
                              --> flags = 2
                              --> accept-encoding: gzip,deflate,sdch
                                  host: jetty.intalio.com:10111
                                  method: GET
                                  referer: https://jetty.intalio.com:10111/spdy/
                                  scheme: https
                                  url: https://jetty.intalio.com:10111https://jetty.intalio.com:10111/spdy/logo.jpg
                                  version: HTTP/1.1
                                  x-spdy-push: true
                              --> id = 6

So it seems to me that a broken server push implementation seems to be able to let chromium crash. Please find at the end of the email the macos crash report for chromium. Let me know if I can provide further details for you or if I should change the server behavior for you in some way.

Cheers,
Thomas

Comment 11 by rtenneti@chromium.org, Aug 1 2012

HttpNetworkTransactionSpdy3Test.CrossOriginProxyPush fails with call stack in comment #2 if ":status" is not sent as part of the headers.

This crash may not be same as tbecker@ issue (unless spdy proxy was also involved in his test case).

[ RUN      ] HttpNetworkTransactionSpdy3Test.CrossOriginProxyPush
[91892:90876:0731/205148:1469466066:FATAL:spdy_stream.cc(108)] Check failed: 0U == pending_buffers_.size() (0 vs. 2)
Backtrace:
	base::debug::StackTrace::StackTrace [0x10070731+33] (d:\src\tree1\src\base\debug\stack_trace_win.cc:149)
	logging::LogMessage::~LogMessage [0x100CA18E+94] (d:\src\tree1\src\base\logging.cc:563)
	net::SpdyStream::PushedStreamReplayData [0x02C58A87+343] (d:\src\tree1\src\net\spdy\spdy_stream.cc:108)
	base::internal::RunnableAdapter<void (__thiscall net::SpdyStream::*)(void)>::Run [0x02C63221+33] (d:\src\tree1\src\base\bind_internal.h:134)
	base::internal::InvokeHelper<0,void,base::internal::RunnableAdapter<void (__thiscall net::SpdyStream::*)(void)>,void __cdecl(net::SpdyStream * const &)>::MakeItSo [0x02C6312A+26] (d:\src\tree1\src\base\bind_internal.h:871)
	base::internal::Invoker<1,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall net::SpdyStream::*)(void)>,void __cdecl(net::SpdyStream *),void __cdecl(net::SpdyStream *)>,void __cdecl(net::SpdyStream *)>::Run [0x02C62F19+73] (d:\src\tree1\src\base\bind_internal.h:1172)
	base::Callback<void __cdecl(void)>::Run [0x1005A2EF+47] (d:\src\tree1\src\base\callback.h:388)
	MessageLoop::RunTask [0x100D493F+591] (d:\src\tree1\src\base\message_loop.cc:462)
	MessageLoop::DeferOrRunPendingTask [0x100D4BC4+52] (d:\src\tree1\src\base\message_loop.cc:475)
	MessageLoop::DoWork [0x100D5A86+262] (d:\src\tree1\src\base\message_loop.cc:648)
	base::MessagePumpForIO::DoRunLoop [0x100EE482+50] (d:\src\tree1\src\base\message_pump_win.cc:497)
	base::MessagePumpWin::RunWithDispatcher [0x100EBF32+130] (d:\src\tree1\src\base\message_pump_win.cc:64)
	base::MessagePumpWin::Run [0x1002455C+28] (d:\src\tree1\src\base\message_pump_win.h:47)
	MessageLoop::RunInternal [0x100D4529+313] (d:\src\tree1\src\base\message_loop.cc:419)
	MessageLoop::RunHandler [0x100D427E+46] (d:\src\tree1\src\base\message_loop.cc:393)
	base::RunLoop::Run [0x10150809+41] (d:\src\tree1\src\base\run_loop.cc:46)
	MessageLoop::Run [0x100D3551+81] (d:\src\tree1\src\base\message_loop.cc:300)
	net::internal::TestCompletionCallbackBaseInternal::WaitForResult [0x012FB674+308] (d:\src\tree1\src\net\base\test_completion_callback.cc:26)
	net::internal::TestCompletionCallbackTemplate<int>::WaitForResult [0x004D7EE9+25] (d:\src\tree1\src\net\base\test_completion_callback.h:53)
	net::HttpNetworkTransactionSpdy3Test_CrossOriginProxyPush_Test::TestBody [0x00A2DF9B+2379] (d:\src\tree1\src\net\http\http_network_transaction_spdy3_unittest.cc:5124)
	testing::internal::HandleExceptionsInMethodIfSupported<testing::Test,void> [0x01384A7C+316] (d:\src\tree1\src\testing\gtest\src\gtest.cc:2126)
	testing::Test::Run [0x0136E08E+174] (d:\src\tree1\src\testing\gtest\src\gtest.cc:2143)
	testing::TestInfo::Run [0x0136EAFD+221] (d:\src\tree1\src\testing\gtest\src\gtest.cc:2323)
	testing::TestCase::Run [0x0136F29F+239] (d:\src\tree1\src\testing\gtest\src\gtest.cc:2427)
	testing::internal::UnitTestImpl::RunAllTests [0x01375DAD+701] (d:\src\tree1\src\testing\gtest\src\gtest.cc:4250)
	testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl,bool> [0x01385594+324] (d:\src\tree1\src\testing\gtest\src\gtest.cc:2126)
	testing::UnitTest::Run [0x01374610+192] (d:\src\tree1\src\testing\gtest\src\gtest.cc:3884)
	base::TestSuite::Run [0x0135ADF8+296] (d:\src\tree1\src\base\test\test_suite.cc:242)
	main [0x0061DC56+150] (d:\src\tree1\src\net\base\run_all_unittests.cc:43)
	__tmainCRTStartup [0x013A2858+424] (f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c:586)
	mainCRTStartup [0x013A269F+15] (f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c:403)
	BaseThreadInitThunk [0x76CC3677+18]
	RtlInitializeExceptionChain [0x77649F42+99]
	RtlInitializeExceptionChain [0x77649F15+54]

Comment 12 by infe...@chromium.org, Aug 1 2012

Labels: SecImpacts-Stable SecImpacts-Beta

Comment 13 by cbentzel@chromium.org, Aug 1 2012

Owner: rtenneti@chromium.org
Status: Assigned

Comment 14 by cbentzel@chromium.org, Aug 1 2012

Is this SPDY2 specific or does it also impact SPDY/3?

Comment 15 by rtenneti@chromium.org, Aug 1 2012

Summary: SPDY - Pushed stream - crash accessing https://jetty.intalio.com:10111/spdy
This bug exists in SPDY/2 and SPDY/3 (updated the summary).

Comment 16 by rtenneti@chromium.org, Aug 3 2012

After disabling the DCHECK in SpdyStream::PushedStreamReplayData (in the original) post, got the following crash.

Was able to fix the following and other crashes when client receives data frame, but it hasn't received (status header) and uploaded the CL for review and will commit asap.

[8200:39568:1604474838:VERBOSE1:client_side_detection_host.cc(216)] Instruct renderer to start phishing detection for URL: https://jetty.intalio.com:10111/spdy/
[8200:41392:1604474885:FATAL:spdy_http_stream.cc(395)] Check failed: response_headers_received_. 
Backtrace:
	base::debug::StackTrace::StackTrace [0x10070731+33] (d:\src\tree1\src\base\debug\stack_trace_win.cc:149)
	logging::LogMessage::~LogMessage [0x100CA18E+94] (d:\src\tree1\src\base\logging.cc:563)
	net::SpdyHttpStream::OnDataReceived [0x092D1516+262] (d:\src\tree1\src\net\spdy\spdy_http_stream.cc:395)
	net::SpdyStream::OnDataReceived [0x0932B5BC+1260] (d:\src\tree1\src\net\spdy\spdy_stream.cc:422)
	net::SpdySession::OnStreamFrameData [0x092E9D26+262] (d:\src\tree1\src\net\spdy\spdy_session.cc:1247)
	net::BufferedSpdyFramer::OnStreamFrameData [0x092BA444+52] (d:\src\tree1\src\net\spdy\buffered_spdy_framer.cc:160)
	net::SpdyFramer::ProcessDataFramePayload [0x092C5F70+208] (d:\src\tree1\src\net\spdy\spdy_framer.cc:961)
	net::SpdyFramer::ProcessInput [0x092BF9BD+1197] (d:\src\tree1\src\net\spdy\spdy_framer.cc:354)
	net::BufferedSpdyFramer::ProcessInput [0x092BA6F1+33] (d:\src\tree1\src\net\spdy\buffered_spdy_framer.cc:200)
	net::SpdySession::OnReadComplete [0x092E5593+563] (d:\src\tree1\src\net\spdy\spdy_session.cc:800)

Comment 17 by rtenneti@chromium.org, Aug 6 2012

Was able to crash on Linux after couple of times trying. The following is the crash id.

http://crash.corp.google.com/reportdetail?reportid=7a6eaef1ed3585ff
Thread 12 *CRASHED* ( SIGSEGV @ 0x00000030 )

0x7fe375060280	 [chrome]	 - net/http/http_network_transaction.cc:860 (cs|src|ann)]	
net::HttpNetworkTransaction::DoReadHeadersComplete
0x7fe375061029	 [chrome]	 - net/http/http_network_transaction.cc:560 (cs|src|ann)]	
net::HttpNetworkTransaction::DoLoop
0x7fe3750611c8	 [chrome]	 - net/http/http_network_transaction.cc:496 (cs|src|ann)]	
net::HttpNetworkTransaction::OnIOComplete
0x7fe3750b5dd7	 [chrome]	 - ./base/callback.h:311 (cs|src|ann)]	
net::SpdyHttpStream::DoCallback
0x7fe3750c1cd6	 [chrome]	 - net/spdy/spdy_session.cc:1141 (cs|src|ann)]	
net::SpdySession::DeleteStream
0x7fe3750cc566	 [chrome]	 - net/spdy/spdy_stream.cc:404 (cs|src|ann)]	
net::SpdyStream::OnDataReceived
0x7fe3750c5041	 [chrome]	 - net/spdy/spdy_session.cc:1231 (cs|src|ann)]	
net::SpdySession::OnStreamFrameData
0x7fe3750b2ebf	 [chrome]	 - net/spdy/spdy_framer.cc:904 (cs|src|ann)]	
net::SpdyFramer::ProcessDataFramePayload
0x7fe3750b535d	 [chrome]	 - net/spdy/spdy_framer.cc:354 (cs|src|ann)]	
net::SpdyFramer::ProcessInput
0x7fe3750c37c4	 [chrome]	 - net/spdy/spdy_session.cc:763 (cs|src|ann)]	
net::SpdySession::OnReadComplete

CL https://chromiumcodereview.appspot.com/10836084/ fixes this crash.

Comment 18 by rtenneti@chromium.org, Aug 6 2012

It is crashing at the following line on linux (per the crash id in comment# 17).

 if (response_.headers->GetParsedHttpVersion() < HttpVersion(1, 0)) {

Comment 19 by bugdroid1@chromium.org, Aug 6 2012

Project Member
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=150121

------------------------------------------------------------------------
r150121 | rtenneti@chromium.org | 2012-08-06T18:53:47.888186Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_network_transaction_spdy2_unittest.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_network_transaction_spdy3_unittest.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_websocket_stream.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session_spdy2_unittest.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_websocket_stream.h?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session_spdy3_unittest.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_proxy_client_socket.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_stream_test_util.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_proxy_client_socket.h?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_stream_test_util.h?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_http_stream.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_stream.cc?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_http_stream.h?r1=150121&r2=150120&pathrev=150121
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_stream.h?r1=150121&r2=150120&pathrev=150121

SPDY - Handle incomplete headers during server push.

If we receive a data frame without a status or without
a version header, we close the stream with a PROTOCOL ERROR.

Small bug fix to HttpNetworkTransaction to access the
ResponseHeaders only if headers are there.

In SpdyStream, retrun a SPDY_PROTOCOL_ERROR if we have pending
data frames, but we haven't received "status" and "version"
headers. (rch: removed the DCHECK for unit tests).

SpdyHttpStream's OnDataReceived used to expect that it would
be called only when all required headers are received. Converted
the DCHECK into an error condition and SpdyStream closes the
stream with PROTOCOL ERROR if OnDataReceived returns a network
error.

BUG= 135485 
R=rch@chromium.org
TEST=network unittests

Review URL: https://chromiumcodereview.appspot.com/10836084
------------------------------------------------------------------------

Comment 20 by rtenneti@chromium.org, Aug 6 2012

If we want to merge this change in M21, if we merge just the http_network_transaction.cc, it will the crash in comment# 17 (and the null pointer dereferencing reported by  tbecker@. thanks.

http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=150121&r2=150120&pathrev=150121

Comment 21 by rtenneti@chromium.org, Aug 6 2012

Labels: Merge-Requested
Would like to merge following change (which accesses header only if they are not NULL) to http_network_transaction.cc to M21 to fix the security bug.

    if (stream_->CanFindEndOfResponse()) {
      HttpResponseHeaders* headers = GetResponseHeaders();
      if (headers)
        keep_alive = headers->IsKeepAlive();
    }

thanks
raman

Comment 22 by kareng@google.com, Aug 6 2012

go a CL?

Comment 23 by rtenneti@chromium.org, Aug 6 2012

Hi kareng:
  The following is the CL. 

https://chromiumcodereview.appspot.com/10832170/

Comment 24 by rtenneti@chromium.org, Aug 7 2012

Cc: jsc...@chromium.org
IMO, this crash is due to dereferencing of a NULL pointer (it is not due use after tree). cbentzel@ mentioned it may not be a critical security fix. 

jschuh@: Should we merge this change into M21?

thanks
raman

Comment 25 by cbentzel@chromium.org, Aug 8 2012

rtenneti described it as a null-pointer deref only, so that's why I assumed low severity (also marked as SecSeverity-Low). Security folks will make the call though.

Comment 26 by kareng@google.com, Aug 9 2012

i assume security will approve this then.

Comment 27 by cbentzel@chromium.org, Aug 14 2012

Should this be considered fixed (if not fully merged)?

Comment 28 by scarybea...@gmail.com, Aug 14 2012

Labels: -Restrict-View-SecurityTeam -Merge-Requested Restrict-View-SecurityNotify Merge-Approved
Status: FixUnreleased
Seems so simple that we should merge it.

Comment 29 by bugdroid1@chromium.org, Aug 20 2012

Project Member
Labels: -Merge-Approved merge-merged-1180
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=152353

------------------------------------------------------------------------
r152353 | rtenneti@google.com | 2012-08-20T17:41:04.513101Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1180/src/net/http/http_network_transaction.cc?r1=152353&r2=152352&pathrev=152353

SPDY - Handle incomplete headers during server push.

Small fix to check for headers before accessing them.

Original review URL:
https://chromiumcodereview.appspot.com/10832170/

R=scarybeasts@gmail.com, rch@chromium.org
BUG= 135485 
TEST=network unit tests and accessing https://jetty.intalio.com:10111/spdy/
crashes the browser on Linux
Review URL: https://chromiumcodereview.appspot.com/10829349
------------------------------------------------------------------------

Comment 30 by rtenneti@chromium.org, Aug 20 2012

Status: Fixed

Comment 31 by scarybea...@gmail.com, Aug 29 2012

Labels: CVE-2012-2867

Comment 32 by bugdroid1@chromium.org, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 33 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Type-Security -Area-Internals -Internals-Network-SPDY -SecSeverity-Low -Mstone-21 -SecImpacts-Stable -SecImpacts-Beta Security-Impact-Stable Security-Impact-Beta Security-Severity-Low M-21 Cr-Internals Cr-Internals-Network-SPDY Type-Bug-Security

Comment 34 by bugdroid1@chromium.org, Mar 13 2013

Project Member
Labels: Restrict-View-EditIssue

Comment 35 by bugdroid1@chromium.org, Mar 14 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 36 by scarybea...@gmail.com, Mar 21 2013

Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue

Comment 37 by bugdroid1@chromium.org, Mar 21 2013

Project Member
Labels: -Security-Severity-Low Security_Severity-Low

Comment 38 by bugdroid1@chromium.org, Mar 21 2013

Project Member
Labels: -Security-Impact-Stable Security_Impact-Stable

Comment 39 by bugdroid1@chromium.org, Mar 21 2013

Project Member
Labels: -Security-Impact-Beta Security_Impact-Beta

Comment 40 by laforge@google.com, Mar 4 2015

Labels: -Cr-Internals-Network-SPDY Cr-Internals-Network-HTTP2
Migrate from Cr-Internals-Network-SPDY to Cr-Internals-Network-HTTP2

Comment 41 by sheriffbot@chromium.org, Jun 14 2016

Project Member
Labels: -security_impact-beta

Comment 42 by sheriffbot@chromium.org, Oct 1 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 43 by sheriffbot@chromium.org, Oct 2 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 44 by mbarbe...@chromium.org, Oct 2 2016

Labels: allpublic

Comment 45 by awhalley@chromium.org, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment