[
https://issues.apache.org/jira/browse/TS-3378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14573003#comment-14573003
]
ASF GitHub Bot commented on TS-3378:
------------------------------------
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/211#issuecomment-108941270
Alan looked over this yesterday and noted that we could set the FetchSM
UserData to NULL when we free the SpdyRequest, rather than store the stream ID
and look it up on each use.
I made that change, but noticed that FetchSM is being destroyed at the same
time the SpdyRequest is freed. I think due to locking, the FetchSM isn't
really destroyed yet, so I went ahead and added the UserDataSet(NULL). In this
particular stack track it doesn't appear that the FetchSM object has been freed
yet.
So I think this change makes things better, but we still have the potential
of a rogue freed FetchSM floating around.
> SpdyRequest used after free()
> -----------------------------
>
> Key: TS-3378
> URL: https://issues.apache.org/jira/browse/TS-3378
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
> Reporter: Leif Hedstrom
> Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
>
> I see this on our docs.ts machine:
> {code}
> ==1310==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x6110004fc974 at pc 0x7c2162 bp 0x7fff97c95010 sp 0x7fff97c95008
> READ of size 1 at 0x6110004fc974 thread T0 ([ET_NET 0])
> #0 0x7c2161 in spdy_process_fetch
> /usr/local/src/trafficserver/proxy/spdy/SpdyClientSession.cc:339
> #1 0x7c2161 in SpdyClientSession::state_session_readwrite(int, void*)
> /usr/local/src/trafficserver/proxy/spdy/SpdyClientSession.cc:253
> #2 0x4f1308 in Continuation::handleEvent(int, void*)
> ../iocore/eventsystem/I_Continuation.h:146
> #3 0x4f1308 in FetchSM::InvokePluginExt(int)
> /usr/local/src/trafficserver/proxy/FetchSM.cc:250
> #4 0x4f455a in FetchSM::fetch_handler(int, void*)
> /usr/local/src/trafficserver/proxy/FetchSM.cc:516
> #5 0x59f737 in Continuation::handleEvent(int, void*)
> ../iocore/eventsystem/I_Continuation.h:146
> #6 0x59f737 in PluginVC::process_write_side(bool)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:519
> #7 0x5aa2fd in PluginVC::main_handler(int, void*)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:210
> #8 0xc6aabe in Continuation::handleEvent(int, void*)
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #9 0xc6aabe in EThread::process_event(Event*, int)
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:144
> #10 0xc6d0d9 in EThread::execute()
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:238
> #11 0x498481 in main /usr/local/src/trafficserver/proxy/Main.cc:1759
> #12 0x2b01d58c0af4 in __libc_start_main (/lib64/libc.so.6+0x21af4)
> #13 0x4ab124 (/opt/ats/bin/traffic_server+0x4ab124)
> 0x6110004fc974 is located 52 bytes inside of 224-byte region
> [0x6110004fc940,0x6110004fca20)
> freed by thread T0 ([ET_NET 0]) here:
> #0 0x2b01d1d2e1c7 in __interceptor_free
> ../../.././libsanitizer/asan/asan_malloc_linux.cc:62
> #1 0x7c8433 in ClassAllocator<SpdyRequest>::free(SpdyRequest*)
> ../../lib/ts/Allocator.h:138
> #2 0x7c8433 in SpdyClientSession::cleanup_request(int)
> /usr/local/src/trafficserver/proxy/spdy/SpdyClientSession.h:146
> #3 0x7c8433 in
> spdy_prepare_status_response_and_clean_request(SpdyClientSession*, int, char
> const*) /usr/local/src/trafficserver/proxy/spdy/SpdyCa
> llbacks.cc:85
> #4 0x7c1094 in spdy_process_fetch
> /usr/local/src/trafficserver/proxy/spdy/SpdyClientSession.cc:354
> #5 0x7c1094 in SpdyClientSession::state_session_readwrite(int, void*)
> /usr/local/src/trafficserver/proxy/spdy/SpdyClientSession.cc:253
> #6 0x4f1c95 in Continuation::handleEvent(int, void*)
> ../iocore/eventsystem/I_Continuation.h:146
> #7 0x4f1c95 in FetchSM::InvokePluginExt(int)
> /usr/local/src/trafficserver/proxy/FetchSM.cc:259
> #8 0x4f2eaa in FetchSM::process_fetch_read(int)
> /usr/local/src/trafficserver/proxy/FetchSM.cc:465
> #9 0x4f4542 in FetchSM::fetch_handler(int, void*)
> /usr/local/src/trafficserver/proxy/FetchSM.cc:514
> #10 0x59e077 in Continuation::handleEvent(int, void*)
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x59e077 in PluginVC::process_read_side(bool)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:640
> #12 0x5aab79 in PluginVC::main_handler(int, void*)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:206
> #13 0xc6aabe in Continuation::handleEvent(int, void*)
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #14 0xc6aabe in EThread::process_event(Event*, int)
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:144
> #15 0xc6d0d9 in EThread::execute()
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:238
> #16 0x498481 in main /usr/local/src/trafficserver/proxy/Main.cc:1759
> #17 0x2b01d58c0af4 in __libc_start_main (/lib64/libc.so.6+0x21af4)
> previously allocated by thread T5 ([ET_NET 4]) here:
> #0 0x2b01d1d2e93b in __interceptor_posix_memalign
> ../../.././libsanitizer/asan/asan_malloc_linux.cc:130
> #1 0x2b01d2c18309 in ats_memalign
> /usr/local/src/trafficserver/lib/ts/ink_memory.cc:96
> #2 0x7c89ba in ClassAllocator<SpdyRequest>::alloc()
> ../../lib/ts/Allocator.h:124
> #3 0x7c89ba in spdy_on_ctrl_recv_callback(spdylay_session*,
> spdylay_frame_type, spdylay_frame*, void*)
> /usr/local/src/trafficserver/proxy/spdy/Spd
> yCallbacks.cc:328
> #4 0x2b01d3f1afff in spdylay_session_call_on_ctrl_frame_received
> /admin/src/spdylay/lib/spdylay_session.c:1634
> #5 0x2b01d3f1afff in spdylay_session_on_syn_stream_received
> /admin/src/spdylay/lib/spdylay_session.c:1782
> #6 0x300000166 (+0x270009166)
> Thread T5 ([ET_NET 4]) created by T0 ([ET_NET 0]) here:
> #0 0x2b01d1cfd86a in __interceptor_pthread_create
> ../../.././libsanitizer/asan/asan_interceptors.cc:183
> #1 0xc6a365 in ink_thread_create ../../lib/ts/ink_thread.h:148
> #2 0xc6a365 in Thread::start(char const*, unsigned long, void*
> (*)(void*), void*)
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:103
> #3 0xc728e6 in EventProcessor::start(int, unsigned long)
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEventProcessor.cc:140
> #4 0x4981f6 in main /usr/local/src/trafficserver/proxy/Main.cc:1572
> #5 0x2b01d58c0af4 in __libc_start_main (/lib64/libc.so.6+0x21af4)
> SUMMARY: AddressSanitizer: heap-use-after-free
> /usr/local/src/trafficserver/proxy/spdy/SpdyClientSession.cc:339
> spdy_process_fetch
> {code}
> From what it looks, we cleanup the "req" member in
> {code}
> cleanup_request(int streamId);
> {code}
> But the req is still being used (and the pointer is not cleared either) after
> this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
