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

Issue 135485 link

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

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

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

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?
 
Cc: gr...@intalio.com sbor...@intalio.com
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]

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.
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.
Does this crash happen in release builds ?
I was able to duplicate it in stable channel with  --enable-npn and accessing  https://jetty.intalio.com:10111/spdy/ on Linux.
Labels: SecSeverity-Low Mstone-21
Back from vacation now. What's the status here?

Comment 9 Deleted

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

Labels: SecImpacts-Stable SecImpacts-Beta
Owner: rtenneti@chromium.org
Status: Assigned
Is this SPDY2 specific or does it also impact SPDY/3?
Summary: SPDY - Pushed stream - crash accessing https://jetty.intalio.com:10111/spdy
This bug exists in SPDY/2 and SPDY/3 (updated the summary).
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)
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.

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

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

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

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
------------------------------------------------------------------------
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
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?
Hi kareng:
  The following is the CL. 

https://chromiumcodereview.appspot.com/10832170/
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
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.
Should this be considered fixed (if not fully merged)?
Labels: -Restrict-View-SecurityTeam -Merge-Requested Restrict-View-SecurityNotify Merge-Approved
Status: FixUnreleased
Seems so simple that we should merge it.
Project Member

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

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
------------------------------------------------------------------------
Status: Fixed
Labels: CVE-2012-2867
Project Member

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

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.
Project Member

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

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

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

Labels: Restrict-View-EditIssue
Project Member

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

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

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

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

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

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

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

Labels: -Security-Impact-Beta Security_Impact-Beta
Labels: -Cr-Internals-Network-SPDY Cr-Internals-Network-HTTP2
Migrate from Cr-Internals-Network-SPDY to Cr-Internals-Network-HTTP2
Project Member

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

Labels: -security_impact-beta
Project Member

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

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

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

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
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment