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

Issue 653366 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

chromium quic net::ProofSource smart-pointer is not safe

Reported by sni...@gmail.com, Oct 6 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Example URL:
.

Steps to reproduce the problem:
1. launch quic_server
2. stree test
  a. make a mass volume of quic client
    - each request consist without QuicServerConfig
    - after request client will teardown everything ...
3. quic_server are creash

when I run a quic server with address sanitizer 
I see about ProofSource heep-use-after-free

=================================================================
==148447==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000066cd8 at pc 0x0000008f3ae1 bp 0x7f9f0dd16640 sp 0x7f9f0dd16638
READ of size 4 at 0x604000066cd8 thread T79 (dispatch thread)
    #0 0x8f3ae0 in Release base/memory/ref_counted.h:68:9
    #1 0x8f3ae0 in Release base/memory/ref_counted.h:136:0
    #2 0x8f3ae0 in Release base/memory/ref_counted.h:407:0
    #3 0x8f3ae0 in ~scoped_refptr base/memory/ref_counted.h:311:0
    #4 0x8f3ae0 in ~QuicCryptoProof net/quic/crypto/quic_crypto_server_config.cc:1841:0
    #5 0x12b212c in ~QuicCryptoServerStream net/quic/quic_crypto_server_stream.cc:72:1
    #6 0x12b21fd in ?? net/quic/quic_crypto_server_stream.cc:70:51
    #7 0xe85fdd in operator() buildtools/third_party/libc++/trunk/include/memory:2529:13
    #8 0xe85fdd in reset buildtools/third_party/libc++/trunk/include/memory:2735:0
    #9 0xe85fdd in ~unique_ptr buildtools/third_party/libc++/trunk/include/memory:2703:0
    #10 0xe85fdd in ~QuicServerSessionBase net/tools/quic/quic_server_session_base.cc:35:0
    #11 0x639b01 in ~ServerSession trident_stellite/stellite/server/server_session.cc:45:1
    #12 0x639b01 in ~ServerSession trident_stellite/stellite/server/server_session.cc:44:0
    #13 0xe7f6cc in STLDeleteContainerPointers<std::__1::__wrap_iter<net::QuicServerSessionBase **> > base/stl_util.h:44:5
    #14 0xe7f6cc in STLDeleteElements<std::__1::vector<net::QuicServerSessionBase *, std::__1::allocator<net::QuicServerSessionBase *> > > base/stl_util.h:135:0
    #15 0x8ff75a in Run<net::(anonymous namespace)::QuicChromeAlarm *> base/bind_internal.h:186:12
    #16 0x8ff75a in MakeItSo<base::WeakPtr<net::(anonymous namespace)::QuicChromeAlarm>> base/bind_internal.h:324:0
    #17 0x8ff75a in Run base/bind_internal.h:362:0
    #18 0x56ae74 in Run base/callback.h:397:12
    #19 0x56ae74 in RunTask base/debug/task_annotator.cc:51:0
    #20 0x500135 in RunTask base/message_loop/message_loop.cc:478:3
    #21 0x500cd5 in DeferOrRunPendingTask base/message_loop/message_loop.cc:487:5
    #22 0x501c3c in DoWork base/message_loop/message_loop.cc:604:13
    #23 0x5678e0 in Run base/message_loop/message_pump_libevent.cc:217:21
    #24 0x5269f8 in Run base/run_loop.cc:35:3
    #25 0x4ff09e in ?? base/message_loop/message_loop.cc:294:3
    #26 0x5c6570 in ThreadMain base/threading/thread.cc:254:3
    #27 0x53a994 in ThreadFunc base/threading/platform_thread_posix.cc:70:3
    #28 0x7f9f706f7dc4 in start_thread pthread_create.c:?

0x604000066cd8 is located 8 bytes inside of 40-byte region [0x604000066cd0,0x604000066cf8)
freed by thread T31 (dispatch thread) here:
    #0 0x4e2f6b in operator delete(void*) ??:?
    #1 0x8f3aa6 in Release base/memory/ref_counted.h:137:7
    #2 0x8f3aa6 in Release base/memory/ref_counted.h:407:0
    #3 0x8f3aa6 in ~scoped_refptr base/memory/ref_counted.h:311:0
    #4 0x8f3aa6 in ~QuicCryptoProof net/quic/crypto/quic_crypto_server_config.cc:1841:0
    #5 0x12b212c in ~QuicCryptoServerStream net/quic/quic_crypto_server_stream.cc:72:1
    #6 0x12b21fd in ?? net/quic/quic_crypto_server_stream.cc:70:51
    #7 0xe85fdd in operator() buildtools/third_party/libc++/trunk/include/memory:2529:13
    #8 0xe85fdd in reset buildtools/third_party/libc++/trunk/include/memory:2735:0
    #9 0xe85fdd in ~unique_ptr buildtools/third_party/libc++/trunk/include/memory:2703:0
    #10 0xe85fdd in ~QuicServerSessionBase net/tools/quic/quic_server_session_base.cc:35:0
    #11 0x639b01 in ~ServerSession trident_stellite/stellite/server/server_session.cc:45:1
    #12 0x639b01 in ~ServerSession trident_stellite/stellite/server/server_session.cc:44:0
    #13 0xe7f6cc in STLDeleteContainerPointers<std::__1::__wrap_iter<net::QuicServerSessionBase **> > base/stl_util.h:44:5
    #14 0xe7f6cc in STLDeleteElements<std::__1::vector<net::QuicServerSessionBase *, std::__1::allocator<net::QuicServerSessionBase *> > > base/stl_util.h:135:0
    #15 0x8ff75a in Run<net::(anonymous namespace)::QuicChromeAlarm *> base/bind_internal.h:186:12
    #16 0x8ff75a in MakeItSo<base::WeakPtr<net::(anonymous namespace)::QuicChromeAlarm>> base/bind_internal.h:324:0
    #17 0x8ff75a in Run base/bind_internal.h:362:0
    #18 0x56ae74 in Run base/callback.h:397:12
    #19 0x56ae74 in RunTask base/debug/task_annotator.cc:51:0
    #20 0x500135 in RunTask base/message_loop/message_loop.cc:478:3
    #21 0x500cd5 in DeferOrRunPendingTask base/message_loop/message_loop.cc:487:5
    #22 0x501c3c in DoWork base/message_loop/message_loop.cc:604:13
    #23 0x5678e0 in Run base/message_loop/message_pump_libevent.cc:217:21
    #24 0x5269f8 in Run base/run_loop.cc:35:3
    #25 0x4ff09e in ?? base/message_loop/message_loop.cc:294:3
    #26 0x5c6570 in ThreadMain base/threading/thread.cc:254:3
    #27 0x53a994 in ThreadFunc base/threading/platform_thread_posix.cc:70:3
    #28 0x7f9f706f7dc4 in start_thread pthread_create.c:?

previously allocated by thread T0 here:
    #0 0x4e29ab in operator new(unsigned long) ??:?
    #1 0x5e2ecb in Initialize net/quic/crypto/proof_source_chromium.cc:54:12
    #2 0x4e50a3 in main trident_stellite/stellite/quic_thread_server_main.cc:92:8
    #3 0x7f9f7013ab14 in __libc_start_main ??:?

Thread T79 (dispatch thread) created by T0 here:
    #0 0x4a1cd6 in __interceptor_pthread_create ??:?
    #1 0x53a32a in CreateThread base/threading/platform_thread_posix.cc:109:13
    #2 0x5c5cf9 in StartWithOptions base/threading/thread.cc:116:10
    #3 0x62a687 in Start trident_stellite/stellite/server/thread_worker.cc:68:3
    #4 0x6248a5 in Start trident_stellite/stellite/server/quic_thread_server.cc:60:5
    #5 0x4e52a0 in main trident_stellite/stellite/quic_thread_server_main.cc:117:3
    #6 0x7f9f7013ab14 in __libc_start_main ??:?

Thread T31 (dispatch thread) created by T0 here:
    #0 0x4a1cd6 in __interceptor_pthread_create ??:?
    #1 0x53a32a in CreateThread base/threading/platform_thread_posix.cc:109:13
    #2 0x5c5cf9 in StartWithOptions base/threading/thread.cc:116:10
    #3 0x62a687 in Start trident_stellite/stellite/server/thread_worker.cc:68:3
    #4 0x6248a5 in Start trident_stellite/stellite/server/quic_thread_server.cc:60:5
    #5 0x4e52a0 in main trident_stellite/stellite/quic_thread_server_main.cc:117:3
    #6 0x7f9f7013ab14 in __libc_start_main ??:?

SUMMARY: AddressSanitizer: heap-use-after-free (/home1/irteam/quic-server/quic_thread_server+0x8f3ae0)
==148447==AddressSanitizer: while reporting a bug found another one. Ignoring.
Shadow bytes around the buggy address:
  0x0c0880004d40: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x0c0880004d50: fa fa 00 00 00 00 00 fa fa fa fd fd fd fd fd fd
  0x0c0880004d60: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x0c0880004d70: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x0c0880004d80: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
=>0x0c0880004d90: fa fa fd fd fd fd fd fd fa fa fd[fd]fd fd fd fa
  0x0c0880004da0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x0c0880004db0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
  0x0c0880004dc0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x0c0880004dd0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
  0x0c0880004de0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==148447==ABORTING

What is the expected behavior?
no crash

What went wrong?
quic proof code are crashed

Did this work before? N/A 

Chrome version: 52.0.2743.117  Channel: n/a
OS Version: CentOS Linux release 7.2.1511
Flash Version: -

quic server are build using https://github.com/line/stellite
 

Comment 1 by sni...@gmail.com, Oct 6 2016

  a. make a mass volume of quic client
    {
        httpClient = new TestRunner.HttpClient();
        httpClient.initWithQuicHost(host, false);  //initialized with QUIC_ONLY

        // synchronized request
        int response = httpClient.get(TEST_URL); // this URL support QUIC_ONLY request
        httpClient.tearDown();
    }
    

Comment 2 by sni...@gmail.com, Oct 6 2016

and test chromium tag is 52.0.2743.117

Comment 3 by mattm@chromium.org, Oct 6 2016

Components: -Internals>Network Internals>Network>QUIC
Appears from allocation trace "#1 0x5e2ecb in Initialize net/quic/crypto/proof_source_chromium.cc:54:12" that this is actually related to ProofSource::Chain.

ProofSource::Chain is a base::RefCounted, NOT a RefCountedThreadSafe, so it appears the problem is with the multi-threaded way stellite is using quic, is not how it is intended to be used.

Quic folks: should this be closed?

Comment 4 by sni...@gmail.com, Oct 7 2016

I see, please close this issue. thanks!!

I'll change to use QuicServerCryptoConfig, with reentrant on each worker thread
Cc: sureshkumari@chromium.org
Status: WontFix (was: Unconfirmed)
As per the comment-4 we are closing the issue.

Sign in to add a comment