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.

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

saber -dfree double free path and free() lines not showing #1520

Open
mxHuber opened this issue Aug 18, 2024 · 0 comments
Open

saber -dfree double free path and free() lines not showing #1520

mxHuber opened this issue Aug 18, 2024 · 0 comments

Comments

@mxHuber
Copy link
Contributor

mxHuber commented Aug 18, 2024

I am trying to use the ./saber -dfree tool to analyze c and cpp programs for CWE-415 double free vulnerabilities. The output says that a double free has been found and correctly prints the line of the memory allocation, but does not print the free() locations.

I have created a small example program to demonstrate this.

DoubleFreeSimple1.cpp

#include <cstdlib>

int main() {
  int *Data = (int *)malloc(sizeof(int));

  *Data = 1;

  free(Data);
  free(Data);

  return 0;
}

Compilation command

wllvm++ -g -S -c -Xclang -disable-O0-optnone -fno-discard-value-names -emit-llvm DoubleFreeSimple1.cpp -o DoubleFreeSimple1.ll

svf command

./saber DoubleFreeSimple1.ll -dfree

relevant svf output

svf-output

What I've tried

I have tried to find the part of the code that causes this, but was unable to do so. The sinks have been correctly found and are present at the time SrcSnkDDA::analyze is called. The lines of the free() calls are correctly identified as line 8 and 9.

svf_print_sinks
svf_print_output

I have noticed that the bugEventStack.size() is always 1, even in more sophisticated test programs. The first element is the memory allocation, which is correctly printed. The loop afterwards goes from the second element to the last element to print the path. Since the size of bugEventStack is always 1, this loop doesn't run at all, which explains the empty path.

My guess then is that the sinks are not being analyzed/not being analyzed correctly in the SrcSnkDDA::analyze function, but the bug could be somewhere else as well. It could also be, that I have made a mistake and used svf incorrectly, so if this is the case, please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant