RESOLVED WONTFIX 266653
[WebRTC] Fix logic when parsing H264 packets to make sure the buffer isn't exceeded
https://bugs.webkit.org/show_bug.cgi?id=266653
Summary [WebRTC] Fix logic when parsing H264 packets to make sure the buffer isn't ex...
Nicole Rosario
Reported 2023-12-19 12:07:05 PST
rdar://118861473 INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 1871439528 INFO: Loaded 2 modules (741459 inline 8-bit counters): 741309 [0x11657d1c0, 0x11663217d), 150 [0x1008bc000, 0x1008bc096), ./Release/rtp_packetizer_h264_fuzzer: Running 1 inputs 1 time(s) each. Running: /Users/nicolerosario/Desktop/Bugs/118861473/ptf_1701108736_593a.tc # # Fatal error in: /Users/nicolerosario/Desktop/BrowserSecurity_3/OpenSource/Source/ThirdParty/libwebrtc/Source/webrtc/modules/rtp_rtcp/source/rtp_format_h264.cc, line 292 # last system error: 3 # Check failed: index + kLengthFieldSize + fragment.size() <= payload_capacity (502 vs. 374) # ==67474== ERROR: libFuzzer: deadly signal #0 0x1011d9a34 in __sanitizer_print_stack_trace+0x2c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x5da34) #1 0x1008ae0e4 in fuzzer::PrintStackTrace() FuzzerUtil.cpp:210 #2 0x1008913cc in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp:233 #3 0x183d57a20 in _sigtramp+0x34 (libsystem_platform.dylib:arm64e+0x3a20) #4 0x183d28cbc in pthread_kill+0x11c (libsystem_pthread.dylib:arm64e+0x6cbc) #5 0x183c34a3c in abort+0xb0 (libsystem_c.dylib:arm64e+0x76a3c) #6 0x1102d3fbc in rtc::webrtc_checks_impl::WriteFatalLog(std::__1::basic_string_view<char, std::__1::char_traits<char>>) checks.cc:78 #7 0x1102d4188 in rtc::webrtc_checks_impl::WriteFatalLog(char const*, int, std::__1::basic_string_view<char, std::__1::char_traits<char>>) checks.cc:84 #8 0x1102d5418 in rtc::webrtc_checks_impl::FatalLog(char const*, int, char const*, rtc::webrtc_checks_impl::CheckArgType const*, ...) checks.cc:179 #9 0x1126af36c in webrtc::RtpPacketizerH264::NextAggregatePacket(webrtc::RtpPacketToSend*) rtp_format_h264.cc:292 #10 0x1126ad764 in webrtc::RtpPacketizerH264::NextPacket(webrtc::RtpPacketToSend*) rtp_format_h264.cc:268 #11 0x100874fa0 in webrtc::FuzzOneInput(unsigned char const*, unsigned long) rtp_packetizer_h264_fuzzer.cc:66 #12 0x10087a010 in LLVMFuzzerTestOneInput webrtc_fuzzer_main.cc:39 #13 0x100892838 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) FuzzerLoop.cpp:617 #14 0x10087db24 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) FuzzerDriver.cpp:324 #15 0x100882fd8 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) FuzzerDriver.cpp:860 #16 0x1008af5d4 in main FuzzerMain.cpp:20 #17 0x1839a90dc (<unknown module>) NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal
Attachments
Nicole Rosario
Comment 1 2023-12-21 13:00:45 PST
David Kilzer (:ddkilzer)
Comment 2 2024-01-22 20:45:03 PST
GitHub PR was closed. We're fixing this a different way.
Note You need to log in before you can comment on or make changes to this bug.