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
NULL deref crash in m_copydata #382
Labels
Comments
markwo
added a commit
to markwo/usrsctp
that referenced
this issue
Sep 26, 2019
I added a stand-alone repro program in this branch: I build the project as follows: Then run repro/repro_382. Output:
|
tuexen
added a commit
to sctplab/stream-reset-improved
that referenced
this issue
Oct 5, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382
tuexen
added a commit
to sctplab/SCTP_NKE_ElCapitan
that referenced
this issue
Oct 5, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382
tuexen
added a commit
to sctplab/SCTP_NKE_Yosemite
that referenced
this issue
Oct 5, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382
tuexen
added a commit
to sctplab/SCTP_NKE_HighSierra
that referenced
this issue
Oct 5, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382
tuexen
added a commit
to sctplab/pr-sctp-improved
that referenced
this issue
Oct 5, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382
tuexen
added a commit
to sctplab/sctp-idata
that referenced
this issue
Oct 5, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382
tuexen
added a commit
that referenced
this issue
Oct 5, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in #382
uqs
pushed a commit
to freebsd/freebsd-src
that referenced
this issue
Oct 5, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382 MFC after: 3 days git-svn-id: svn+ssh://svn.freebsd.org/base/head@353119 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
to freebsd/freebsd-src
that referenced
this issue
Oct 5, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382 MFC after: 3 days
mat813
pushed a commit
to mat813/freebsd
that referenced
this issue
Oct 7, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382 MFC after: 3 days git-svn-id: https://svn.freebsd.org/base/head@353119 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Tested, the fix looks good. |
uqs
pushed a commit
to freebsd/freebsd-src
that referenced
this issue
Oct 10, 2019
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
uqs
pushed a commit
to freebsd/freebsd-src
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
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 git-svn-id: https://svn.freebsd.org/base/stable/12@353398 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
fichtner
pushed a commit
to opnsense/src
that referenced
this issue
Oct 29, 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@)
brooksdavis
pushed a commit
to CTSRD-CHERI/cheribsd
that referenced
this issue
Oct 30, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382 MFC after: 3 days
bdrewery
pushed a commit
to bdrewery/freebsd
that referenced
this issue
Nov 18, 2019
Thanks to Mark Wodrich who found this issue while fuzz testing the usrsctp stack and reported the issue in sctplab/usrsctp#382 MFC after: 3 days git-svn-id: svn+ssh://svn.freebsd.org/base/head@353119 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
to freebsd/freebsd-src
that referenced
this issue
May 7, 2020
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
mat813
pushed a commit
to mat813/freebsd
that referenced
this issue
Jun 9, 2020
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 git-svn-id: https://svn.freebsd.org/base/stable/11@360742 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
taylor-b
pushed a commit
to taylor-b/usrsctp
that referenced
this issue
Apr 1, 2021
taylor-b
pushed a commit
to taylor-b/usrsctp
that referenced
this issue
May 3, 2021
taylor-b
pushed a commit
to taylor-b/usrsctp
that referenced
this issue
May 11, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I hit this crash during fuzzing - it looks similar to #351 but reproduces with the current code in master.
PCAP is attached.
repro.pcap.zip
The text was updated successfully, but these errors were encountered: