Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NULL deref crash in m_copydata #351

Closed
markwo opened this issue Aug 21, 2019 · 5 comments
Closed

NULL deref crash in m_copydata #351

markwo opened this issue Aug 21, 2019 · 5 comments
Assignees
@tuexen
Labels
bug

Comments

@markwo
Copy link

markwo commented Aug 21, 2019

While working on a fuzzer for usrsctp, I hit a SEGV accessing a NULL pointer. The PCAP is attached - output and stack trace of the crash are below.

I'm cleaning up the fuzzer currently - can share the code if you need it to repro. (Would also like to eventually get this fuzzer added to the repo as an OSS-Fuzz target).

I 14:41:15.285924 0000 13 88 13 88 00 00 00 00 ab c0 54 a5 01 00 00 56 11 4f e7 17 00 02 00 00 00 04 00 04 4f d4 56 32 c0 00 00 04 80 08 00 09 c0 0f c1 80 82 00 00 00 80 02 00 24 1b 5e 9b 0f 4d 23 8a 48 8f 55 ab 62 e5 cf 31 6a 61 ad 64 37 db 19 0c 77 7f d3 1c 71 cc c0 2c 7d 80 04 00 06 00 01 00 00 80 03 00 06 80 c1 00 00 # SCTP_PACKET

O 14:41:15.286064 0000 13 88 13 88 00 00 00 00 00 00 00 00 01 00 00 14 01 00 00 00 00 00 20 00 00 08 00 08 00 00 00 01 # SCTP_PACKET

I 14:41:15.286129 0000 13 88 13 88 01 00 00 00 00 00 00 00 02 00 01 4c 11 4f e7 17 00 02 00 00 00 04 00 04 4f d4 56 32 c0 00 00 04 80 08 00 09 c0 0f c1 80 82 00 00 00 80 02 00 24 ec 62 55 07 81 f3 ec 7c 91 45 9b 4e ab db fa 62 92 ad 74 15 7d b0 6a 62 ad c0 bb 36 ec 51 af 7e 80 04 00 06 00 01 00 00 80 03 00 06 80 c1 00 00 00 07 00 f4 4b 41 4d 45 2d 42 53 44 20 31 2e 31 00 00 00 00 7b ba 5d 5d 00 00 00 00 93 5d 04 00 00 00 00 00 60 ea 00 00 0c 67 e3 72 d1 ee db 86 00 00 00 01 11 4f e7 17 00 02 00 00 e0 60 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 02 00 00 e0 60 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 13 88 13 88 00 00 01 00 01 01 01 00 00 00 00 00 01 00 00 14 01 00 00 00 00 00 20 00 00 08 00 08 00 00 00 01 02 00 01 4c 11 4f e7 17 00 02 00 00 00 04 00 04 4f d4 56 32 c0 00 00 04 80 08 00 09 c0 0f c1 80 82 00 00 00 80 02 00 24 ec 62 55 07 81 f3 ec 7c 91 45 9b 4e ab db fa 62 92 ad 74 15 7d b0 6a 62 ad c0 bb 36 ec 51 af 7e 80 04 00 06 00 01 00 00 80 03 00 06 80 c1 00 00 b5 d7 6f d0 87 36 4c 76 c2 da 27 54 29 f0 dd a1 02 f8 dc f7 # SCTP_PACKET

O 14:41:15.286169 0000 13 88 13 88 11 4f e7 17 00 00 00 00 02 01 01 84 01 0a 01 01 0a 61 61 61 01 81 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 0a 01 01 00 ff 05 00 00 00 00 00 00 00 00 00 15 15 40 0b 40 e5 78 00 7a 02 09 00 00 00 00 00 30 00 00 00 40 0b 40 00 00 00 00 00 00 bc bc bc bc bc bc bc df d2 00 06 00 75 00 00 00 c0 00 05 00 00 00 04 01 c0 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 04 01 ff 00 04 01 f7 00 07 00 75 00 00 00 c0 00 05 00 00 00 04 01 c0 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 00 07 00 75 00 00 00 c0 00 05 00 00 00 04 01 c0 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 04 01 ff 00 04 01 f7 00 07 00 74 00 00 00 c0 00 05 00 00 00 04 01 c0 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 04 01 ff 00 04 ff ff ff ff ff 01 c0 00 04 01 ff 00 04 01 f7 00 07 00 75 00 00 00 c0 00 05 00 00 00 04 01 c0 00 04 ff 00 04 01 c0 00 04 01 ff 00 04 00 c0 00 05 00 00 00 04 01 c0 00 04 ff 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 04 01 ff 00 04 01 c0 00 04 01 ff 00 04 01 f7 00 07 00 75 00 00 00 c0 00 05 00 00 00 04 01 c0 00 04 01 c0 00 04 0a 01 0a 01 01 0a 01 ff # SCTP_PACKET
AddressSanitizer:DEADLYSIGNAL
=================================================================
==92873==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000018 (pc 0x55d5ae7c49fa bp 0x7ffdf5d37680 sp 0x7ffdf5d37650 T0)
==92873==The signal is caused by a READ memory access.
==92873==Hint: address points to the zero page.
    #0 0x55d5ae7c49f9 in m_copydata third_party/usrsctp/usrsctplib/user_mbuf.c:1394:11
    #1 0x55d5ae879bd8 in sctp_copy_mbufchain third_party/usrsctp/usrsctplib/netinet/sctp_output.c:6996:5
    #2 0x55d5ae8504d3 in sctp_med_chunk_output third_party/usrsctp/usrsctplib/netinet/sctp_output.c:8867:16
    #3 0x55d5ae848f02 in sctp_chunk_output third_party/usrsctp/usrsctplib/netinet/sctp_output.c:10670:11
    #4 0x55d5ae7d21e0 in sctp_process_control third_party/usrsctp/usrsctplib/netinet/sctp_input.c:5108:5
    #5 0x55d5ae7f2b79 in sctp_common_input_processing third_party/usrsctp/usrsctplib/netinet/sctp_input.c:5886:10
    #6 0x55d5ae78dcb7 in usrsctp_conninput third_party/usrsctp/usrsctplib/user_socket.c:3478:2
    #7 0x55d5ae77aa5a in usrsctp_fuzzer::SctpSocket::SctpSocket()::$_0::operator()(std::__u::unique_ptr<RawBuffer, std::__u::default_delete<RawBuffer> >) const third_party/usrsctp/fuzzer/usrsctp_fuzzer.cc:152:46
    #8 0x55d5ae77a921 in decltype(std::__u::forward<usrsctp_fuzzer::SctpSocket::SctpSocket()::$_0&>(fp)(std::__u::forward<std::__u::unique_ptr<RawBuffer, std::__u::default_delete<RawBuffer> > >(fp0))) std::__u::__invoke<usrsctp_fuzzer::SctpSocket::SctpSocket()::$_0&, std::__u::unique_ptr<RawBuffer, std::__u::default_delete<RawBuffer> > >(usrsctp_fuzzer::SctpSocket::SctpSocket()::$_0&, std::__u::unique_ptr<RawBuffer, std::__u::default_delete<RawBuffer> >&&) third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/type_traits:3530:1
    #9 0x55d5ae76f590 in usrsctp_fuzzer::MessageSocket::ReceiveData(std::__u::unique_ptr<RawBuffer, std::__u::default_delete<RawBuffer> >) third_party/usrsctp/fuzzer/usrsctp_fuzzer.cc:103:5
    #10 0x55d5ae77ce81 in usrsctp_fuzzer::SctpFuzzer::SetUp()::$_2::operator()(std::__u::unique_ptr<RawBuffer, std::__u::default_delete<RawBuffer> >) const third_party/usrsctp/fuzzer/usrsctp_fuzzer.cc:410:19
    #11 0x55d5ae77ccb1 in decltype(std::__u::forward<usrsctp_fuzzer::SctpFuzzer::SetUp()::$_2&>(fp)
[null_deref.zip](https://github.com/sctplab/usrsctp/files/3527529/null_deref.zip)
[null_deref.zip](https://github.com/sctplab/usrsctp/files/3527534/null_deref.zip)

(std::__u::forward<std::__u::unique_ptr<RawBuffer, std::__u::default_delete<RawBuffer> > >(fp0))) std::__u::__invoke<usrsctp_fuzzer::SctpFuzzer::SetUp()::$_2&, std::__u::unique_ptr<RawBuffer, std::__u::default_delete<RawBuffer> > >(usrsctp_fuzzer::SctpFuzzer::SetUp()::$_2&, std::__u::unique_ptr<RawBuffer, std::__u::default_delete<RawBuffer> >&&) third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/type_traits:3530:1
    #12 0x55d5ae76f9b5 in usrsctp_fuzzer::MessageSocket::ProcessNextWriteInQueue() third_party/usrsctp/fuzzer/usrsctp_fuzzer.cc:119:3
    #13 0x55d5ae771dbc in usrsctp_fuzzer::SctpFuzzer::PumpMessages() third_party/usrsctp/fuzzer/usrsctp_fuzzer.cc:719:22
    #14 0x55d5ae7738c4 in LLVMFuzzerTestOneInput third_party/usrsctp/fuzzer/usrsctp_fuzzer.cc:757:8
    #15 0x55d5ae93e476 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) third_party/llvm/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:554:15
    #16 0x55d5ae928589 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) third_party/llvm/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:292:6
    #17 0x55d5ae92d7ce in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) third_party/llvm/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:775:9
    #18 0x55d5ae946fd2 in main third_party/llvm/llvm/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
    #19 0x7fd8de447bbc in __libc_start_main (/usr/grte/v4/lib64/libc.so.6+0x38bbc)
    #20 0x55d5ae6bd768 in _start /usr/grte/v4/debug-src/src/csu/../sysdeps/x86_64/start.S:108

null_deref.zip
@weinrank
Copy link
Contributor

Hey @markwo,

I'm interested in your fuzzer code. We're already fuzzing our project with libfuzz and are preparing it for OSS-FUZZ integration.
Additional fuzzers are welcome! :)

Please send an email to weinrank@fh-muenster.de

best regards

@benjwright benjwright mentioned this issue Aug 21, 2019
Closed
@tuexen tuexen self-assigned this Aug 22, 2019
@tuexen tuexen added the bug label Aug 22, 2019
@tuexen
Copy link
Member

tuexen commented Aug 22, 2019

Can be reproduced with the following packetdrill script:

 0.0 socket(..., SOCK_STREAM, IPPROTO_SCTP) = 3
+0.0 bind(3, ..., ...) = 0
+0.0 fcntl(3, F_GETFL) = 0x02 (flags O_RDWR)
+0.0 fcntl(3, F_SETFL, O_RDWR | O_NONBLOCK) = 0
+0.1 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
+0.0 > sctp: INIT[flgs=0, tag=1, a_rwnd=..., os=..., is=..., tsn=0, ...]
+0.0 < sctp: [0x02, 0x01, 0x01, 0x84, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x61, 0x61, 0x61, 0x01, 0x81, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x00, 0xff, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x15, 0x15, 0x40, 0x0b, 0x40, 0xe5, 0x78, 0x00, 0x7a, 0x02, 0x09, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, 0x40, 0x0b, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xbc, 0xbc, 0xbc, 0xbc, 0xbc, 0xbc, 0xbc, 0xdf, 0xd2, 0x00, 0x06, 0x00, 0x75, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x05, 0x00, 0x00, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xf7, 0x00, 0x07, 0x00, 0x75, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x05, 0x00, 0x00, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x00, 0x07, 0x00, 0x75, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x05, 0x00, 0x00, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xf7, 0x00, 0x07, 0x00, 0x74, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x05, 0x00, 0x00, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xf7, 0x00, 0x07, 0x00, 0x75, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x05, 0x00, 0x00, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x00, 0xc0, 0x00, 0x05, 0x00, 0x00, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xff, 0x00, 0x04, 0x01, 0xf7, 0x00, 0x07, 0x00, 0x75, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x05, 0x00, 0x00, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x01, 0xc0, 0x00, 0x04, 0x0a, 0x01, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0xff]
+0.0 close(3) = 0

@tuexen tuexen mentioned this issue Aug 30, 2019
Closed
tuexen added a commit that referenced this issue Sep 1, 2019
@tuexen
Improve the handling of state cookie parameters in INIT-ACK chunks.
a5ce87d 
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
#351
and
#352
tuexen added a commit to sctplab/stream-reset-improved that referenced this issue Sep 1, 2019
@tuexen
Improve the handling of state cookie parameters in INIT-ACK chunks.
4f9a49f 
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
sctplab/usrsctp#351
and
sctplab/usrsctp#352
tuexen added a commit to sctplab/SCTP_NKE_Yosemite that referenced this issue Sep 1, 2019
@tuexen
Improve the handling of state cookie parameters in INIT-ACK chunks.
c823b05 
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
sctplab/usrsctp#351
and
sctplab/usrsctp#352
tuexen added a commit to sctplab/SCTP_NKE_ElCapitan that referenced this issue Sep 1, 2019
@tuexen
Improve the handling of state cookie parameters in INIT-ACK chunks.
b9f8104 
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
sctplab/usrsctp#351
and
sctplab/usrsctp#352
tuexen added a commit to sctplab/SCTP_NKE_HighSierra that referenced this issue Sep 1, 2019
@tuexen
Improve the handling of state cookie parameters in INIT-ACK chunks.
6797834 
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
sctplab/usrsctp#351
and
sctplab/usrsctp#352
tuexen added a commit to sctplab/pr-sctp-improved that referenced this issue Sep 1, 2019
@tuexen
Improve the handling of state cookie parameters in INIT-ACK chunks.
8ff6531 
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
sctplab/usrsctp#351
and
sctplab/usrsctp#352
tuexen added a commit to sctplab/sctp-idata that referenced this issue Sep 1, 2019
@tuexen
iImprove the handling of state cookie parameters in INIT-ACK chunks.
3335c75 
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
sctplab/usrsctp#351
and
sctplab/usrsctp#352
@tuexen
Copy link
Member

tuexen commented Sep 1, 2019

@markwo a5ce87d should fix the issue. Can you retest and confirm?

@markwo
Copy link
Author

markwo commented Sep 3, 2019

I can confirm this fixes the issue, thanks!

@markwo markwo closed this as completed Sep 3, 2019
@nxrighthere
Copy link
Contributor

#160 (comment) Might be related to this?

uqs pushed a commit to freebsd/freebsd-src that referenced this issue Sep 7, 2019
@tuexen
MFC r351654:
9e8e6b2 
Improve the handling of state cookie parameters in INIT-ACK chunks.
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
sctplab/usrsctp#351
and
sctplab/usrsctp#352
mat813 pushed a commit to mat813/freebsd that referenced this issue Sep 16, 2019
MFC r351654:
8bb54c3 
Improve the handling of state cookie parameters in INIT-ACK chunks.
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
sctplab/usrsctp#351
and
sctplab/usrsctp#352


git-svn-id: https://svn.freebsd.org/base/stable/12@352007 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
@markwo markwo mentioned this issue Sep 25, 2019
Closed
@taylor-b taylor-b mentioned this issue Apr 14, 2020
Open
hardenedbsd-services pushed a commit to HardenedBSD/hardenedBSD that referenced this issue Jan 29, 2021
@tuexen
MFC r351654:
c88ce0f 
Improve the handling of state cookie parameters in INIT-ACK chunks.
This fixes problem with parameters indicating a zero length or partial
parameters after an unknown parameter indicating to stop processing. It
also fixes a problem with state cookie parameters after unknown
parametes indicating to stop porcessing.
Thanks to Mark Wodrich from Google for finding two of these issues
by fuzz testing the userland stack and reporting them in
sctplab/usrsctp#351
and
sctplab/usrsctp#352
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tuexen tuexen

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tuexen @markwo @weinrank @nxrighthere