Zero-day bugs
Zero-day bugs
Embedded Files
Taking into account the anonymous submission policy, we have erased the bug’s specific issue numbers and the user names. We will make them public once anonymity is no longer a concern.
This bug is located at cv::dnn::dnn4_v20220524::RemoveIdentityOps line 833-840, and is fixed in the commit 18fbb72 . Our report is shown as follows.
Steps to reproduce:
Steps to reproduce:
To reproduce the bug, we only need to call the function readNetFromTensorflow(repro) by the reproduce file. The reproduce file can be download from repro. For example, we can triggered the bug by the simple code on the right:
Root cause of this bug:
Root cause of this bug:
This infinite loop can be triggered once nextIt->second = nextIt->first. In that case, the finding function identity_ops.find() always return nextIt->first and keep doing infinitely.
How does EndWatch find this bug?
How does EndWatch find this bug?
This bug is found by revisit monitoring in EndWatch. EndWatch first make a state slicing to identify the crucial variables under record by the following procedure: 1) "nextIt" is a candidate variable in the branch block (if (nextIt != identity_ops.end()) which leads to exit block. 2) In line 835, nextIt is affected by it->second. Therefore, "It" is another crutial variable to be recorded. 3) "nextIt" is a temporary varaible created within the loop. Thus, we do not record "nextIt". Finaly, by recording and checking "it", we can find a revisit state.
This bug is located at src/draco/compression/mesh/mesh_edgebreaker_decoder_impl.cc, line 716-719 , and it is fixed in the commit e4e34b0. Our report is shown as follows.
Root cause of this bug:
Root cause of this bug:
In this loop corner_table_->SwingLeft() (line 717) maps "corner_n" to another value. If "corner_n" refers to a potential cyclic link-list like strucutre, it will induce a infinite cyclic loop.
How does EndWatch find this bug?
How does EndWatch find this bug?
This bug is found by revisit monitoring. Like the issue in OpenCV, the target variable under recording in this case is “corner_n”, and by revisiting this variable, we were able to find the linked list causing the infinite loop.
Root cause of this bug:
Root cause of this bug:
The loop cannot terminate because the variable "t'' keeps unchanged during the loop iterations.
How does EndWatch find this bug?
How does EndWatch find this bug?
This bug is found by revisit monitoring. The sliced variable under recording in this case is “t”. By recording “t”, we can find this non-termination loop.
This bug is located at llvm/lib/MC/MCParser/AsmParser.cpp, line 710-728. . Our report is shown as follows.
Steps to reproduce:
Steps to reproduce:
Build the latest release version ( or commit 1856935) and run it using the input poc.zip. Then run it by fuzz_asm_x86_32, fuzz_asm_ppc32be, or fuzz_asm_x86_64.
$: unzip poc.zip
$: cd keystone
$: mkdir build
$: cd build
$: cmake ..
$: make
$: ./suite/fuzz/fuzz_asm_x86_32 -i poc
Root cause of this bug:
Root cause of this bug:
In this loop, there is a stuck path where all the variables keep unchanged, i.e., both of the two "if" branch condition return false.
How does EndWatch find this bug?
How does EndWatch find this bug?
This bug is found by SRC. As shown in the figure, EndWatch instrument "r" and "q" to record the post condition and branch conditons in each iteration. If "r" is true, that means the execution has fallen into the stuck path.
Page updated
Google Sites
Report abuse