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.

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

LeakSanitizer: direct leak of 256 bytes allocated from m_getm2->m_get #396

Closed
markwo opened this issue Oct 4, 2019 · 3 comments

Comments

@markwo
Copy link

commented Oct 4, 2019

==112482==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 256 byte(s) in 1 object(s) allocated from:
    #0 0x4f37f7 in malloc (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x4f37f7)
    #1 0xd0e153 in m_get (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0xd0e153)
    #2 0xd16476 in m_getm2 (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0xd16476)
    #3 0x59adb1 in sctp_get_mbuf_for_msg (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x59adb1)
    #4 0x6e86f7 in sctp_arethere_unrecognized_parameters (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x6e86f7)
    #5 0x629b01 in sctp_process_init_ack (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x629b01)
    #6 0x5e3390 in sctp_handle_init_ack (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x5e3390)
    #7 0x5c7fc9 in sctp_process_control (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x5c7fc9)
    #8 0x5b3c49 in sctp_common_input_processing (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x5b3c49)
    #9 0x584408 in usrsctp_conninput (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x584408)
    #10 0x53612b in main (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x53612b)
    #11 0x7f65ccc5152a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2352a)

Indirect leak of 256 byte(s) in 1 object(s) allocated from:
    #0 0x4f37f7 in malloc (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x4f37f7)
    #1 0xd0e153 in m_get (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0xd0e153)
    #2 0xd330f6 in m_copym (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0xd330f6)
    #3 0x6eb8a5 in sctp_arethere_unrecognized_parameters (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x6eb8a5)
    #4 0x629b01 in sctp_process_init_ack (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x629b01)
    #5 0x5e3390 in sctp_handle_init_ack (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x5e3390)
    #6 0x5c7fc9 in sctp_process_control (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x5c7fc9)
    #7 0x5b3c49 in sctp_common_input_processing (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x5b3c49)
    #8 0x584408 in usrsctp_conninput (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x584408)
    #9 0x53612b in main (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_leak+0x53612b)
    #10 0x7f65ccc5152a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2352a)

SUMMARY: AddressSanitizer: 512 byte(s) leaked in 2 allocation(s).

Output from the repro app (will add to my repro branch in a bit...)

vrf_id 0x0: adding address: AF_CONN address: 0x1
[P][0.000] usrsctp initialized
SCTP: add HMAC id 1 to list
SCTP: added chunk 193 (0xc1) to Auth list
SCTP: added chunk 128 (0x80) to Auth list
Bind called port: 5000
Addr: IPv4 address: 0.0.0.0:5000
Main hash to bind at head:0x625000000198, bound port:5000 - in tcp_pool=0
[P][0.000] Calling usrsctp_connect()
Allocate an association for peer:AF_CONN address: 0x1
Port:5001
Adding an address (from:1) to the peer: AF_CONN address: 0x1
Association 0x61d000001480 now allocated
Sending INIT
Sending INIT - calls lowlevel_output
[P][0.000] Found outgoing INIT, extracting VTAG : 1714556343

O 13:50:31.740020 0000 13 88 13 89 00 00 00 00 00 00 00 00 01 00 00 5a b7 0d 32 66 00 02 00 00 00 0a 08 00 d4 5e e9 58 80 00 00 04 c0 00 00 04 80 08 00 09 c0 0f c1 80 82 00 00 00 80 02 00 24 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 80 04 00 06 00 01 00 00 80 03 00 06 80 c1 00 00 # SCTP_PACKET
[P][0.000] Injecting INIT

I 13:50:31.740173 0000 13 89 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
stcb:0x61d000001480 inp:0x619000000580
stcb is 0x61d000001480
Ok, Common input processing called, m:0x61100001a300 iphlen:0 offset:12 length:32 stcb:0x61d000001480
stcb:0x61d000001480 state:2
sctp_process_control: iphlen=0, offset=12, length=32 stcb:0x61d000001480
Its an INIT of len:20 vtag:0
sctp_process_control: processing a chunk type=1, len=20
SCTP_INIT
sctp_handle_init: handling INIT tcb:0x61d000001480
sctp_handle_init: sending INIT-ACK
Check for unrecognized param's

O 13:50:31.740459 0000 13 88 13 89 01 00 00 00 00 00 00 00 02 00 01 54 b7 0d 32 66 00 02 00 00 00 08 08 00 d4 5e e9 58 80 00 00 04 c0 00 00 04 80 08 00 09 c0 0f c1 80 82 00 00 00 80 02 00 24 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 80 04 00 06 00 01 00 00 80 03 00 06 80 c1 00 00 00 07 00 f8 4b 41 4d 45 2d 42 53 44 20 31 2e 31 00 00 00 00 97 b0 97 5d 00 00 00 00 b3 4b 0b 00 00 00 00 00 60 ea 00 00 0e 82 74 41 25 5d 05 17 00 00 00 01 b7 0d 32 66 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 13 89 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 54 b7 0d 32 66 00 02 00 00 00 08 08 00 d4 5e e9 58 80 00 00 04 c0 00 00 04 80 08 00 09 c0 0f c1 80 82 00 00 00 80 02 00 24 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 80 04 00 06 00 01 00 00 80 03 00 06 80 c1 00 00 1d f3 e7 1e f8 95 2a da 1c 74 6a 19 16 98 62 ee 7c 25 d0 32 # SCTP_PACKET
[P][0.000] Injecting 2nd packet

I 13:50:31.740530 0000 13 89 13 88 b7 0d 32 66 00 00 00 00 02 04 00 20 00 e9 00 08 c0 05 00 00 00 08 00 08 fb ff c9 ff 80 03 00 06 fb fe 00 1b fb ff 00 04 # SCTP_PACKET
Ok, Common input processing called, m:0x61100001ae40 iphlen:0 offset:12 length:44 stcb:0x61d000001480
stcb:0x61d000001480 state:2
sctp_process_control: iphlen=0, offset=12, length=44 stcb:0x61d000001480
sctp_process_control: processing a chunk type=2, len=32
SCTP_INIT_ACK
sctp_handle_init_ack: handling INIT-ACK
Check for unrecognized param's
Hit default param fbff
report op err
move on

O 13:50:31.740617 0000 13 88 13 89 b7 0d 32 66 00 00 00 00 06 01 00 0e 00 02 00 0a 00 00 00 01 00 07 00 00 # SCTP_PACKET
return from send is 0
[P][0.001] Calling usrsctp_close()
markwo added a commit to markwo/usrsctp that referenced this issue Oct 4, 2019
@tuexen tuexen self-assigned this Oct 5, 2019
@tuexen tuexen added the bug label Oct 5, 2019
@tuexen

This comment has been minimized.

Copy link
Member

commented Oct 5, 2019

Build the project using:

cmake -DCMAKE_C_COMPILER=/usr/bin/clang-8 -Dsctp_build_repro=1 -Dsctp_sanitizer_memory=0 -Dsctp_sanitizer_address=1 -Dsctp_debug=1 .
tuexen added a commit to sctplab/stream-reset-improved that referenced this issue Oct 5, 2019
tuexen added a commit to sctplab/pr-sctp-improved that referenced this issue Oct 5, 2019
tuexen added a commit to sctplab/sctp-idata that referenced this issue Oct 5, 2019
tuexen added a commit to sctplab/SCTP_NKE_ElCapitan that referenced this issue Oct 5, 2019
tuexen added a commit to sctplab/SCTP_NKE_Yosemite that referenced this issue Oct 5, 2019
tuexen added a commit to sctplab/SCTP_NKE_HighSierra that referenced this issue Oct 5, 2019
tuexen added a commit that referenced this issue Oct 5, 2019
@tuexen

This comment has been minimized.

Copy link
Member

commented Oct 5, 2019

@markwo I think the issue is fixed in a6417e0. Please retest and report.

uqs pushed a commit to freebsd/freebsd that referenced this issue Oct 5, 2019
userland stack and reporting it in:
sctplab/usrsctp#396

MFC after:		3 days


git-svn-id: svn+ssh://svn.freebsd.org/base/head@353122 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs pushed a commit to freebsd/freebsd that referenced this issue Oct 5, 2019
opntr-auto added a commit to HardenedBSD/hardenedBSD that referenced this issue Oct 5, 2019
* freebsd/current/master:
  devfs: plug redundant bwillwrite avoidance
  arm64: rockchip: usb2phy: Add set/get mode
  Fix a use after free bug when removing remote addresses. This bug was found by OSS-Fuzz and reported in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18004
  Plumb an mbuf leak found by Mark Wodrich from Google by fuzz testing the userland stack and reporting it in: sctplab/usrsctp#396
mat813 pushed a commit to mat813/freebsd that referenced this issue Oct 7, 2019
userland stack and reporting it in:
sctplab/usrsctp#396

MFC after:		3 days


git-svn-id: https://svn.freebsd.org/base/head@353122 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
@markwo

This comment has been minimized.

Copy link
Author

commented Oct 7, 2019

Tested, the fix looks good.

@markwo markwo closed this Oct 7, 2019
uqs pushed a commit to freebsd/freebsd that referenced this issue Oct 10, 2019
Plumb an mbuf leak found by Mark Wodrich from Google by fuzz testing the
userland stack and reporting it in:
sctplab/usrsctp#396
uqs pushed a commit to freebsd/freebsd that referenced this issue Oct 10, 2019
Add missing input validation. This could result in reading from
uninitialized memory.
The issue was found by OSS-Fuzz for usrsctp  and reported in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17780

MFS r353396:

Cleanup sctp_asconf_error_response() and ensure that the parameter
is padded as required. This fixes the followig bug reported by
OSS-Fuzz for the usersctp stack:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17790

MFS r353397:

When skipping the address parameter, take the padding into account.

MFS r353398:

Fix the adding of padding to COOKIE-ECHO chunks.

Thanks to Mark Wodrich who found this issue while fuzz testing the
usrsctp stack and reported the issue in
sctplab/usrsctp#382

MFS r353399:

Plumb an mbuf leak found by Mark Wodrich from Google by fuzz testing the
userland stack and reporting it in:
sctplab/usrsctp#396

MFS r353400:

Fix a use after free bug when removing remote addresses.
This bug was found by OSS-Fuzz and reported in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18004

MFS r353401:

Plumb an mbuf leak in a code path that should not be taken. Also avoid
that this path is taken by setting the tail pointer correctly.
There is still bug related to handling unordered unfragmented messages
which were delayed in deferred handling.
This issue was found by OSS-Fuzz testing the usrsctp stack and reported
in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17794

MFS r353403:

Validate length before use it, not vice versa.
r353060 should have contained this...
This fixes
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18070

Approved by:		re (gjb@)
mat813 pushed a commit to mat813/freebsd that referenced this issue Oct 11, 2019
Add missing input validation. This could result in reading from
uninitialized memory.
The issue was found by OSS-Fuzz for usrsctp  and reported in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17780

MFS r353396:

Cleanup sctp_asconf_error_response() and ensure that the parameter
is padded as required. This fixes the followig bug reported by
OSS-Fuzz for the usersctp stack:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17790

MFS r353397:

When skipping the address parameter, take the padding into account.

MFS r353398:

Fix the adding of padding to COOKIE-ECHO chunks.

Thanks to Mark Wodrich who found this issue while fuzz testing the
usrsctp stack and reported the issue in
sctplab/usrsctp#382

MFS r353399:

Plumb an mbuf leak found by Mark Wodrich from Google by fuzz testing the
userland stack and reporting it in:
sctplab/usrsctp#396

MFS r353400:

Fix a use after free bug when removing remote addresses.
This bug was found by OSS-Fuzz and reported in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18004

MFS r353401:

Plumb an mbuf leak in a code path that should not be taken. Also avoid
that this path is taken by setting the tail pointer correctly.
There is still bug related to handling unordered unfragmented messages
which were delayed in deferred handling.
This issue was found by OSS-Fuzz testing the usrsctp stack and reported
in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17794

MFS r353403:

Validate length before use it, not vice versa.
r353060 should have contained this...
This fixes
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18070

Approved by:		re (gjb@)


git-svn-id: https://svn.freebsd.org/base/releng/12.1@353410 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
mat813 pushed a commit to mat813/freebsd that referenced this issue Oct 11, 2019
Plumb an mbuf leak found by Mark Wodrich from Google by fuzz testing the
userland stack and reporting it in:
sctplab/usrsctp#396


git-svn-id: https://svn.freebsd.org/base/stable/12@353399 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.