Null-dereference READ in spvtools::opt::analysis::DefUseManager::UpdateDefUse |
|||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6253839878193152 Fuzzer: libFuzzer_spvtools_opt_legalization_fuzzer Job Type: windows_libfuzzer_chrome_asan Platform Id: windows Crash Type: Null-dereference READ Crash Address: 0x00000000002d Crash State: spvtools::opt::analysis::DefUseManager::UpdateDefUse spvtools::opt::PrivateToLocalPass::GetNewType spvtools::opt::PrivateToLocalPass::MoveVariable Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6253839878193152 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.
,
Oct 16
Predator and CL could not provide any possible suspects. Using Code Search for the file, "def_use_manager.cpp" suspecting the below Cl might have caused this issue Suspect CL: https://chromium.googlesource.com/external/github.com/KhronosGroup/SPIRV-Tools.git/+/c7da51a0855d0d32627b0b38edacc3cb0d407c4f dan sinclair@ -- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks!
,
Oct 16
,
Oct 17
I cannot reproduce this error with the latest spirv-tools. There is an error while parsing the spv file, and it does not reach the optimizer.
,
Oct 24
ClusterFuzz testcase 6253839878193152 is still reproducing on tip-of-tree build (trunk). Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.
,
Oct 30
This crash occurs very frequently on windows platform and is likely preventing the fuzzer spvtools_opt_legalization_fuzzer from making much progress. Fixing this will allow more bugs to be found. Marking this bug as a blocker for next Beta release. If this is incorrect, please add ClusterFuzz-Wrong label and remove the ReleaseBlock-Beta label.
,
Oct 30
Removing the Release Block label as this is not shipped in Chrome at this point. Re-opening as the fuzzer is still encountering the issue.
,
Nov 5
It looks like the fixup_fuzz_result.py does not work correctly on Windows. The output is suppose to be a binary file, but it is output to stdout which does text. This causes newlines to be changed on windows. After I fix that up, the test case does not pass the validator. I do not see it getting into the optimizer in any circumstance. I'll assign to Dan to fix up the the python script and update the fuzzing tests accordingly.
,
Nov 5
Removing the multiple of 4 restriction on spriv-dis you can get the below which still contains an error about storage class:
; SPIR-V
; Version: 1.0
; Generator: Unknown(34629); 256
; Bound: 3825208973
; Schema: 16505835
OpCapability Tessellation
OpMemoryModel Logical GLSL450
OpEntryPoint Fragment %4 "iS�fE������G"
OpExecutionMode %4 OriginUpperLeft
OpSource HLSL 1376298
OpDecorate %float DescriptorSet 8412197
%void = OpTypeVoid
%3 = OpTypeFunction %void
%float = OpTypeFloat 32
%v4float = OpTypeVector %float 4
%_struct_8 = OpTypeStruct %v4float
%_ptr_Uniform__struct_8 = OpTypePointer Uniform %_struct_8
%_ptr_Private_v4float = OpTypePointer Private %v4float
%_ptr_Output__ptr_Uniform__struct_8 = OpTypePointer Output %_ptr_Uniform__struct_8
%_ptr_UniformConstant__ptr_Output__ptr_Uniform__struct_8 = OpTypePointer UniformConstant %_ptr_Output__ptr_Uniform__struct_8
%int = OpTypeInt 32 4278583550
%int_n720830464 = OpConstant %int -720830464
%_ptr_UniformConstant__ptr_Output__ptr_Uniform__struct_8_0 = OpTypePointer UniformConstant %_ptr_Output__ptr_Uniform__struct_8
%12 = OpVariable %_ptr_Private_v4float Private
%61192 = OpVariable %_ptr_Output__ptr_Uniform__struct_8 Output
%4 = OpFunction %void None %3
%624164864 = OpLabel
error: 88: Invalid storage class operand: 1792
,
Nov 5
Attached the truncated file which should hopefully work on Windows if needed.
,
Nov 6
So, it looks like there are 2 unrelated things going on here. 1- The reason this fails on windows fuzzer and not other platforms is that we are not reading the data into libfuzzer in binary, so when it sees 0d0a in the input stream it's converting it to 0a, we just lose the 0d byte. Which gives a very different 7 value then the 1792 in the other cases. (The opt code reads in binary so it doesn't have this problem, changing libfuzzer to read in binary fixes this problem as well). 2- The next question is, why does this get through validation if the value is 7 instead of 1792 and then fail later, in theory if we can craft an input file it should be reproducible on other platforms as well.
,
Nov 6
Filed issue 902460 for 1- from c#11. Dan, thanks so much for tracking this down. LibFuzzer on Windows is a new thing, and your feedback is very appreciated.
,
Nov 6
With the attached file I get the same crash on linux with the asan fuzzer (I edited the file to remove the 0d so it looks like the input Windows gave).
=================================================================
==166803==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000002d (pc 0x560e3e0fbdb7 bp 0x7ffccbabf850 sp 0x7ffccbabf840 T0)
==166803==The signal is caused by a READ memory access.
==166803==Hint: address points to the zero page.
#0 0x560e3e0fbdb6 in spvtools::opt::Instruction::result_id() const third_party/SPIRV-Tools/src/source/opt/instruction.h:162:12
#1 0x560e3e188c0e in spvtools::opt::analysis::DefUseManager::UpdateDefUse(spvtools::opt::Instruction*) third_party/SPIRV-Tools/src/source/opt/def_use_manager.cpp:77:33
#2 0x560e3e33291d in spvtools::opt::PrivateToLocalPass::GetNewType(unsigned int) third_party/SPIRV-Tools/src/source/opt/private_to_local_pass.cpp:123:14
#3 0x560e3e3324a9 in spvtools::opt::PrivateToLocalPass::MoveVariable(spvtools::opt::Instruction*, spvtools::opt::Function*) third_party/SPIRV-Tools/src/source/opt/private_to_local_pass.cpp:104:26
#4 0x560e3e331eb5 in spvtools::opt::PrivateToLocalPass::Process() third_party/SPIRV-Tools/src/source/opt/private_to_local_pass.cpp:59:5
#5 0x560e3e330764 in spvtools::opt::Pass::Run(spvtools::opt::IRContext*) third_party/SPIRV-Tools/src/source/opt/pass.cpp:112:25
#6 0x560e3e3310d1 in spvtools::opt::PassManager::Run(spvtools::opt::IRContext*) third_party/SPIRV-Tools/src/source/opt/pass_manager.cpp:50:35
#7 0x560e3e0b1ea3 in spvtools::Optimizer::Run(unsigned int const*, unsigned long, std::__1::vector<unsigned int, std::__1::allocator<unsigned int> >*, spv_optimizer_options_t*) const third_party/SPIRV-Tools/src/source/opt/optimizer.cpp:478:37
#8 0x560e3e0b1b5d in spvtools::Optimizer::Run(unsigned int const*, unsigned long, std::__1::vector<unsigned int, std::__1::allocator<unsigned int> >*) const third_party/SPIRV-Tools/src/source/opt/optimizer.cpp:444:10
#9 0x560e3df8ee62 in LLVMFuzzerTestOneInput third_party/SPIRV-Tools/src/test/fuzzers/spvtools_opt_legalization_fuzzer.cpp:35:13
#10 0x560e3dfb59f5 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) third_party/libFuzzer/src/FuzzerLoop.cpp:570:15
#11 0x560e3df99145 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) third_party/libFuzzer/src/FuzzerDriver.cpp:280:6
#12 0x560e3df9f72f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) third_party/libFuzzer/src/FuzzerDriver.cpp:713:9
#13 0x560e3dfc6a9c in main third_party/libFuzzer/src/FuzzerMain.cpp:20:10
#14 0x7f0c8baa72b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
,
Nov 6
This file will disassemble correctly. (Under spirv-opt it runs to completion, but I haven't been able to get spirv-opt to build with ASAN correctly).
; SPIR-V
; Version: 1.0
; Generator: Unknown(34629); 256
; Bound: 3825208973
; Schema: 16505835
OpCapability Tessellation
OpMemoryModel Logical GLSL450
OpEntryPoint Fragment %4 "iS�fE������G"
OpExecutionMode %4 OriginUpperLeft
OpSource HLSL 1376298
OpDecorate %float DescriptorSet 8412197
%void = OpTypeVoid
%3 = OpTypeFunction %void
%float = OpTypeFloat 32
%v4float = OpTypeVector %float 4
%_struct_8 = OpTypeStruct %v4float
%_ptr_Uniform__struct_8 = OpTypePointer Uniform %_struct_8
%_ptr_Private_v4float = OpTypePointer Private %v4float
%_ptr_Output__ptr_Uniform__struct_8 = OpTypePointer Output %_ptr_Uniform__struct_8
%_ptr_UniformConstant__ptr_Output__ptr_Uniform__struct_8 = OpTypePointer UniformConstant %_ptr_Output__ptr_Uniform__struct_8
%int = OpTypeInt 32 4278583550
%int_n720830464 = OpConstant %int -720830464
%_ptr_UniformConstant__ptr_Output__ptr_Uniform__struct_8_0 = OpTypePointer UniformConstant %_ptr_Output__ptr_Uniform__struct_8
%12 = OpVariable %_ptr_Private_v4float Private
%61192 = OpVariable %_ptr_Output__ptr_Uniform__struct_8 Output
%4 = OpFunction %void None %3
%624164864 = OpLabel
%655360 = OpVariable %_ptr_Uniform__struct_8 Function
%13 = OpLoad %v4float %12
%452984833 = OpCompositeConstruct %_struct_8 %13
OpReturn
OpFunctionEnd
,
Nov 6
I'm passing this back to stevenperron@ as it looks like the problem with the modified file is that the Bound is way bigger then the max_id_bound. So, in PrivateToLocalPass::GetNewType we call FindPointerToType which ends up in Module::TakeNextIdBound which returns 0 because id_bound >= max_id_bound. Steven is this now a dup of the other issues you've been looking at?
,
Nov 7
ClusterFuzz has detected this issue as fixed in range 605930:605950. Detailed report: https://clusterfuzz.com/testcase?key=6253839878193152 Fuzzer: libFuzzer_spvtools_opt_legalization_fuzzer Job Type: windows_libfuzzer_chrome_asan Platform Id: windows Crash Type: Null-dereference READ Crash Address: 0x00000000002d Crash State: spvtools::opt::analysis::DefUseManager::UpdateDefUse spvtools::opt::PrivateToLocalPass::GetNewType spvtools::opt::PrivateToLocalPass::MoveVariable Sanitizer: address (ASAN) Fixed: https://clusterfuzz.com/revisions?job=windows_libfuzzer_chrome_asan&range=605930:605950 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6253839878193152 See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing_on_windows.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
,
Nov 7
ClusterFuzz testcase 6253839878193152 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Dec 14
The documentation for reproducing bugs on Windows was moved to: https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by ClusterFuzz
, Oct 12Labels: Test-Predator-Auto-Components