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
,
Oct 6 2016
and test chromium tag is 52.0.2743.117
,
Oct 6 2016
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?
,
Oct 7 2016
I see, please close this issue. thanks!! I'll change to use QuicServerCryptoConfig, with reentrant on each worker thread
,
Oct 7 2016
As per the comment-4 we are closing the issue. |
|||
►
Sign in to add a comment |
|||
Comment 1 by sni...@gmail.com
, Oct 6 2016a. 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(); }