Klever

Sometimes people are interested in checking rules that aren't related with particular API, e.g. mutexes or memory allocation functions, but that can lead to certain vulnerabilities. For instance, there can be a vulnerability group that includes deadlocks and race conditions in one thread (bug kind patterns are "double lock", "double unlock", "locked at exit" and something more specific). Examples of other vulnerability groups are resource leaks, null pointer dereferences and hang ups (e.g. as a consequence of calling might sleep functions in the atomic context). Everything else that isn't matched with any vulnerability group bug kind pattern should belong to vulnerability group "Other".

We need to extend the rule specifications base (add descriptions of vulnerability groups and corresponding bug kind patterns) and add corresponding filtering in tools (RSG or/and VTG).