Description
This test case implements two thread that both lock two shared mutex locks such that if the timing works out, they will cause each other to deadlock. The test case takes a control integer, the names of two control files, and an input string. The control integer and the two control files are used for timing within the test case to ensure that the test case follows an exploiting or benign execution path, and the input string is used as shared data for the threads to act upon. When executing with exploiting input the test case spawns two threads, the first thread (thread A) starts by pausing its execution while the second thread (thread B) locks the second mutex lock. Thread B then pauses its execution and allows thread A to lock the first mutex lock and try to lock the second mutex lock. Thread A will now hang on the call to lock the second mutex lock since thread B holds it, thread B will then try to grab the first mutex lock, but since thread A holds it the system will enter deadlock.
Metadata
- Base program: Tree
- Source Taint: ENVIRONMENT_VARIABLE
- Data Type: SIMPLE
- Data Flow: BASIC
- Control Flow: SEQUENCE
Flaws
Test Suites
Documentation
Have any comments on this test case? Please, send us an email.