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 sctp_timer_start when processing fuzzed ASCONF #380

Closed
markwo opened this issue Sep 25, 2019 · 6 comments
Closed

NULL deref crash in sctp_timer_start when processing fuzzed ASCONF #380

markwo opened this issue Sep 25, 2019 · 6 comments
Assignees
@tuexen
Labels
bug

Comments

@markwo
Copy link

markwo commented Sep 25, 2019

Hit this issue when fuzzing ASCONF chunks. A PCAP is attached.
The crash occurs when sctp_timer_start() is called here:

usrsctp/usrsctplib/netinet/sctp_asconf.c

Line 268 in ac36440

sctp_timer_start(SCTP_TIMER_TYPE_PATHMTURAISE, stcb->sctp_ep, stcb, net);

repro.pcap.zip

usrsctp: sctp_process_control: processing a chunk type=193, len=40
usrsctp: SCTP_ASCONF
usrsctp: handle_asconf: serial number = b5ed35a2h (expected next = b5ed35a2h)
usrsctp: handle_asconf: asconf_limit=80, sequence=b5ed35a2h
usrsctp: handle_asconf: Now processing first ASCONF. Try to delete old cache
usrsctp: process_asconf_add_ip: adding 
usrsctp: IPv4 address: 0.0.0.0:5000
usrsctp: process_asconf_add_ip: using source addr 
usrsctp: AF_CONN address: 0x60c000000280
usrsctp: Adding an address (from:6) to the peer: 
usrsctp: AF_CONN address: 0x60c000000280

AddressSanitizer:DEADLYSIGNAL
=================================================================
==224135==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000025d (pc 0x55e65eaec0f8 bp 0x7ffd0dda18d0 sp 0x7ffd0dda1880 T0)
==224135==The signal is caused by a READ memory access.
==224135==Hint: address points to the zero page.
usrsctp: Timer type 17 goes off

usrsctp: Timer now complete (type = 17)

    #0 0x55e65eaec0f7 in sctp_timer_start third_party/usrsctp/usrsctplib/netinet/sctputil.c:2257:12
    #1 0x55e65eb13566 in sctp_process_asconf_add_ip third_party/usrsctp/usrsctplib/netinet/sctp_asconf.c:268:3
    #2 0x55e65eb11502 in sctp_handle_asconf third_party/usrsctp/usrsctplib/netinet/sctp_asconf.c:742:15
    #3 0x55e65eab9e09 in sctp_process_control third_party/usrsctp/usrsctplib/netinet/sctp_input.c:5492:5
    #4 0x55e65eae1865 in sctp_common_input_processing third_party/usrsctp/usrsctplib/netinet/sctp_input.c:5899:10
    #5 0x55e65ea717e7 in usrsctp_conninput third_party/usrsctp/usrsctplib/user_socket.c:3518:2
    <snip>

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV third_party/usrsctp/usrsctplib/netinet/sctputil.c:2257:12 in sctp_timer_start
==224135==ABORTING
@tuexen
Copy link
Member

tuexen commented Sep 25, 2019

Is it possible to share with @weinrank some information such that @weinrank can run a reproducer locally in our lab?

@markwo
Copy link
Author

markwo commented Sep 25, 2019

Sure, I will send the info tomorrow.

markwo added a commit to markwo/usrsctp that referenced this issue Sep 26, 2019
@markwo
Add simple repro program for Issue sctplab#380
83dd068
@markwo
Copy link
Author

markwo commented Sep 26, 2019

I added a stand-alone repro program in this branch:
https://github.com/markwo/usrsctp/tree/fuzzer_repro

Since the issue is due to an uninitialized pointer on the stack, the crash doesn't always trigger (sctp_timer_start checks for NULL inputs). The best way to catch this is with -fsanitize=memory. I was building the project as follows:
cmake -DCMAKE_C_COMPILER=/usr/bin/clang-8 -Dsctp_build_repro=1 -Dsctp_sanitizer_memory=1 -Dsctp_sanitizer_address=0 -Dsctp_debug=1 .

Then run repro/repro_380. Output:

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

O 15:27:38.195430 0000 13 88 13 89 00 00 00 00 00 00 00 00 01 00 00 5a fb f2 ab ba 00 02 00 00 00 0a 08 00 00 00 00 f8 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.004] Injecting INIT

I 15:27:38.195867 0000 13 89 13 88 00 00 00 00 00 00 00 00 01 00 00 50 01 00 00 00 00 00 20 00 00 08 00 08 00 00 00 01 80 08 00 07 c1 80 0f 00 80 03 00 07 00 c1 80 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 07 00 01 00 00 # SCTP_PACKET
[S][0.004] stcb:0x71d000000000 inp:0x719000000000
[S][0.004] stcb is 0x71d000000000
[S][0.004] Ok, Common input processing called, m:0x710000010100 iphlen:0 offset:12 length:92 stcb:0x71d000000000
[S][0.004] stcb:0x71d000000000 state:2
[S][0.004] sctp_process_control: iphlen=0, offset=12, length=92 stcb:0x71d000000000
[S][0.004] Its an INIT of len:80 vtag:0
[S][0.004] sctp_process_control: processing a chunk type=1, len=80
[S][0.004] SCTP_INIT
[S][0.004] sctp_handle_init: handling INIT tcb:0x71d000000000
[S][0.004] sctp_handle_init: sending INIT-ACK
[S][0.004] Check for unrecognized param's
[S][0.004] Hit default param 8004
[S][0.004] move on

O 15:27:38.196549 0000 13 88 13 89 01 00 00 00 00 00 00 00 02 00 01 90 fb f2 ab ba 00 02 00 00 00 08 08 00 00 00 00 f8 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 01 34 4b 41 4d 45 2d 42 53 44 20 31 2e 31 00 00 00 00 5a 3b 8d 5d 00 00 00 00 f3 fd 02 00 00 00 00 00 60 ea 00 00 e3 00 00 00 46 7c c2 54 00 00 00 01 fb f2 ab ba 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 50 01 00 00 00 00 00 20 00 00 08 00 08 00 00 00 01 80 08 00 07 c1 80 0f 00 80 03 00 07 00 c1 80 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 07 00 01 00 00 02 00 01 90 fb f2 ab ba 00 02 00 00 00 08 08 00 00 00 00 f8 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 b4 82 2a fd b8 68 b3 4b b9 91 4d ad 29 b9 a4 60 61 a3 76 e0 # SCTP_PACKET
[P][0.005] Injecting 2nd packet

I 15:27:38.196602 0000 13 89 13 88 fb f2 ab ba 00 00 00 00 0f 00 00 1c 00 00 00 01 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa c1 0c 00 28 ff ff 9a c1 53 ff 00 08 ff 0c 53 1c c0 01 00 0e 00 00 fe ff 00 05 00 08 00 00 00 00 5d 8b 2c bd ff 04 fc ff # SCTP_PACKET
[S][0.005] Ok, Common input processing called, m:0x710000010200 iphlen:0 offset:12 length:80 stcb:0x71d000000000
[S][0.005] stcb:0x71d000000000 state:2
[S][0.005] sctp_process_control: iphlen=0, offset=12, length=80 stcb:0x71d000000000
[S][0.005] sctp_process_control: processing a chunk type=15, len=28
[S][0.005] SCTP_AUTHENTICATION
[S][0.005] SCTP AUTH Chunk: shared key 0, HMAC id 1
[S][0.005] Recv Key: len 48, [S][0.005] 80[S][0.005] 02[S][0.005] 00[S][0.005] 24[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 41[S][0.005] 80[S][0.005] 03[S][0.005] 00[S][0.005] 06[S][0.005] 80[S][0.005] c1[S][0.005] 80[S][0.005] 04[S][0.005] 00[S][0.005] 06[S][0.005] 00[S][0.005] 01[S][0.005] 
[S][0.005] sctp_process_control: processing a chunk type=193, len=40
[S][0.005] SCTP_ASCONF
[S][0.005] handle_asconf: asconf_limit=80, sequence=f8h
[S][0.005] handle_asconf: Now processing first ASCONF. Try to delete old cache
[S][0.005] process_asconf_add_ip: adding [S][0.005] IPv4 address: 0.0.0.0:5001
[S][0.005] process_asconf_add_ip: using source addr [S][0.005] AF_CONN address: 0x1
[S][0.005] Adding an address (from:6) to the peer: [S][0.005] AF_CONN address: 0x1
==212212==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0xa194d3 in sctp_timer_start (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0xa194d3)
    #1 0xb23167 in sctp_process_asconf_add_ip (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0xb23167)
    #2 0xb1c227 in sctp_handle_asconf (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0xb1c227)
    #3 0x554a23 in sctp_process_control (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0x554a23)
    #4 0x53191a in sctp_common_input_processing (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0x53191a)
    #5 0x5014e0 in usrsctp_conninput (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0x5014e0)
    #6 0x4aca05 in main /usr/local/google/home/markwo/repos/usrsctp/repro/repro_380.c:184:3
    #7 0x7f145e53e52a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2352a)
    #8 0x42a439 in _start (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0x42a439)

  Uninitialized value was stored to memory at
    #0 0xa15115 in sctp_timer_start (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0xa15115)
    #1 0xb23167 in sctp_process_asconf_add_ip (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0xb23167)
    #2 0xb1c227 in sctp_handle_asconf (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0xb1c227)
    #3 0x554a23 in sctp_process_control (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0x554a23)
    #4 0x53191a in sctp_common_input_processing (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0x53191a)
    #5 0x5014e0 in usrsctp_conninput (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0x5014e0)
    #6 0x4aca05 in main /usr/local/google/home/markwo/repos/usrsctp/repro/repro_380.c:184:3
    #7 0x7f145e53e52a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2352a)

  Uninitialized value was created by an allocation of 'net' in the stack frame of function 'sctp_process_asconf_add_ip'
    #0 0xb1f080 in sctp_process_asconf_add_ip (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0xb1f080)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/usr/local/google/home/markwo/repos/usrsctp/repro/repro_380+0xa194d3) in sctp_timer_start

@weinrank
Copy link
Contributor

Same as #386 : We ran into the same issue this night.

@markwo markwo mentioned this issue Sep 27, 2019
Open
tuexen added a commit to sctplab/stream-reset-improved that referenced this issue Sep 30, 2019
@tuexen
Don't use stack memory which is not initialized.
ecc26f1 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
tuexen added a commit to sctplab/SCTP_NKE_Yosemite that referenced this issue Sep 30, 2019
@tuexen
Don't use stack memory which is not initialized.
9451934 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
tuexen added a commit to sctplab/SCTP_NKE_ElCapitan that referenced this issue Sep 30, 2019
@tuexen
Don't use stack memory which is not initialized.
8e62c5c 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
tuexen added a commit to sctplab/SCTP_NKE_HighSierra that referenced this issue Sep 30, 2019
@tuexen
Don't use stack memory which is not initialized.
43c2994 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
tuexen added a commit to sctplab/pr-sctp-improved that referenced this issue Sep 30, 2019
@tuexen
Don't use stack memory which is not initialized.
e1e6df6 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
tuexen added a commit to sctplab/sctp-idata that referenced this issue Sep 30, 2019
@tuexen
Don't use stack memory which is not initialized.
b63e50c 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
tuexen added a commit that referenced this issue Sep 30, 2019
@tuexen
Don't use stack memory which is not initialized.
256ce79 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
@tuexen tuexen added the bug label Sep 30, 2019
@tuexen tuexen self-assigned this Sep 30, 2019
@tuexen
Copy link
Member

tuexen commented Sep 30, 2019

@markwo Please retest and report.

uqs pushed a commit to freebsd/freebsd-src that referenced this issue Sep 30, 2019
Don't use stack memory which is not initialized.
ee12360 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778

MFC after:		3 days


git-svn-id: svn+ssh://svn.freebsd.org/base/head@352894 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs pushed a commit to freebsd/freebsd-src that referenced this issue Sep 30, 2019
@tuexen
Don't use stack memory which is not initialized.
5f8f65d 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778

MFC after:		3 days
@markwo
Copy link
Author

markwo commented Sep 30, 2019

Tested the fix - looks good.

@markwo markwo closed this as completed Sep 30, 2019
opntr-auto added a commit to HardenedBSD/hardenedBSD that referenced this issue Sep 30, 2019
@opntr-auto
Merge branch 'freebsd/current/master' into hardened/current/master
715a256 
* freebsd/current/master:
  Pull in r357528 from upstream llvm trunk (by Craig Topper):
  linux_renameat2: don't add extra \n on error.
  libsysdecode: decode PROT_MAX flags
  Capsicumize nm(1).
  nm: Adjust argc and argv in get_opt().
  Capsicumize c++filt(1).
  Add IFLIB_SINGLE_IRQ_RX_ONLY.
  arm64: rockchip: rk_clk_pll: Check mode on recalc
  arm64: rockchip: correct reset value
  Fix coredump_phnum_test when kern.compress_user_cores != 0
  syscalls.master: consistency, move ); to newline (no functional change)
  Don't use stack memory which is not initialized. Thanks to Mark Wodrich for reporting this issue for the userland stack in sctplab/usrsctp#380 This issue was also found for usrsctp by OSS-fuzz in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
mat813 pushed a commit to mat813/freebsd that referenced this issue Oct 2, 2019
Don't use stack memory which is not initialized.
cec620f 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778

MFC after:		3 days


git-svn-id: https://svn.freebsd.org/base/head@352894 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs pushed a commit to freebsd/freebsd-src that referenced this issue Oct 3, 2019
@tuexen
MFC r352894:
8524660 
Don't use stack memory which is not initialized.
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
uqs pushed a commit to freebsd/freebsd-src that referenced this issue Oct 3, 2019
@tuexen
MFS r352509:
a253651 
Only allow a SCTP-AUTH shared key to be updated by the application
if it is not deactivated and not used.
This avoids a use-after-free problem.

MFS r352674:

Fix the handling of invalid parameters in ASCONF chunks.
Thanks to Mark Wodrich from Google for reproting the issue in
sctplab/usrsctp#376
for the userland stack.

MFS r352675:

Cleanup the RTO calculation and perform some consistency checks
before computing the RTO.
This should fix an overflow issue reported by Felix Weinrank in
sctplab/usrsctp#375
for the userland stack and found by running a fuzz tester.

MFS r352676:

Don't hold the info lock when calling sctp_select_a_tag().
This avoids a double lock bug in the NAT colliding state processing
of SCTP. Thanks to Felix Weinrank for finding and reporting this issue in
sctplab/usrsctp#374
He found this bug using fuzz testing.

MFS r353034:

Plumb a memory leak.
Thanks to Felix Weinrank for finding this issue using fuzz testing
and reporting it for the userland stack:
sctplab/usrsctp#378

MFS r353036:

Don't use stack memory which is not initialized.
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778

Approved by:		re (kib@)
mat813 pushed a commit to mat813/freebsd that referenced this issue Oct 7, 2019
MFC r352894:
875756b 
Don't use stack memory which is not initialized.
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778


git-svn-id: https://svn.freebsd.org/base/stable/12@353036 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
mat813 pushed a commit to mat813/freebsd that referenced this issue Oct 7, 2019
MFS r352509:
9504a1a 
Only allow a SCTP-AUTH shared key to be updated by the application
if it is not deactivated and not used.
This avoids a use-after-free problem.

MFS r352674:

Fix the handling of invalid parameters in ASCONF chunks.
Thanks to Mark Wodrich from Google for reproting the issue in
sctplab/usrsctp#376
for the userland stack.

MFS r352675:

Cleanup the RTO calculation and perform some consistency checks
before computing the RTO.
This should fix an overflow issue reported by Felix Weinrank in
sctplab/usrsctp#375
for the userland stack and found by running a fuzz tester.

MFS r352676:

Don't hold the info lock when calling sctp_select_a_tag().
This avoids a double lock bug in the NAT colliding state processing
of SCTP. Thanks to Felix Weinrank for finding and reporting this issue in
sctplab/usrsctp#374
He found this bug using fuzz testing.

MFS r353034:

Plumb a memory leak.
Thanks to Felix Weinrank for finding this issue using fuzz testing
and reporting it for the userland stack:
sctplab/usrsctp#378

MFS r353036:

Don't use stack memory which is not initialized.
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778

Approved by:		re (kib@)


git-svn-id: https://svn.freebsd.org/base/releng/12.1@353045 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
brooksdavis pushed a commit to CTSRD-CHERI/cheribsd that referenced this issue Oct 24, 2019
@tuexen @brooksdavis
Don't use stack memory which is not initialized.
a431d5d 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778

MFC after:		3 days
fichtner pushed a commit to opnsense/src that referenced this issue Oct 29, 2019
@tuexen @fichtner
MFS r352509:
6cfb164 
Only allow a SCTP-AUTH shared key to be updated by the application
if it is not deactivated and not used.
This avoids a use-after-free problem.

MFS r352674:

Fix the handling of invalid parameters in ASCONF chunks.
Thanks to Mark Wodrich from Google for reproting the issue in
sctplab/usrsctp#376
for the userland stack.

MFS r352675:

Cleanup the RTO calculation and perform some consistency checks
before computing the RTO.
This should fix an overflow issue reported by Felix Weinrank in
sctplab/usrsctp#375
for the userland stack and found by running a fuzz tester.

MFS r352676:

Don't hold the info lock when calling sctp_select_a_tag().
This avoids a double lock bug in the NAT colliding state processing
of SCTP. Thanks to Felix Weinrank for finding and reporting this issue in
sctplab/usrsctp#374
He found this bug using fuzz testing.

MFS r353034:

Plumb a memory leak.
Thanks to Felix Weinrank for finding this issue using fuzz testing
and reporting it for the userland stack:
sctplab/usrsctp#378

MFS r353036:

Don't use stack memory which is not initialized.
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778

Approved by:		re (kib@)
bdrewery pushed a commit to bdrewery/freebsd that referenced this issue Nov 18, 2019
Don't use stack memory which is not initialized.
584ec85 
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778

MFC after:		3 days


git-svn-id: svn+ssh://svn.freebsd.org/base/head@352894 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs pushed a commit to freebsd/freebsd-src that referenced this issue May 7, 2020
@tuexen
MFC r352894: Don't use uninitialized memory.
62fbcf0 
Don't use stack memory which is not initialized.
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778
mat813 pushed a commit to mat813/freebsd that referenced this issue Jun 9, 2020
MFC r352894: Don't use uninitialized memory.
500674e 
Don't use stack memory which is not initialized.
Thanks to Mark Wodrich for reporting this issue for the userland stack in
sctplab/usrsctp#380
This issue was also found for usrsctp by OSS-fuzz in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17778


git-svn-id: https://svn.freebsd.org/base/stable/11@360738 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
taylor-b pushed a commit to taylor-b/usrsctp that referenced this issue Apr 1, 2021
@markwo @taylor-b
Add simple repro program for Issue sctplab#380
82eb2d0
taylor-b pushed a commit to taylor-b/usrsctp that referenced this issue May 3, 2021
@markwo @taylor-b
Add simple repro program for Issue sctplab#380
0745e3f
taylor-b pushed a commit to taylor-b/usrsctp that referenced this issue May 11, 2021
@markwo @taylor-b
Add simple repro program for Issue sctplab#380
b2c5559
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
3 participants
@tuexen @markwo @weinrank