Regarding the Null pointer derefernce in calloc

[anzosasuke]

So i was analyzing the binary using this checker,

1. in 001026aa, it says null pointer dereference, it is a potential dereference, right and not the actual null pointer dereferencing?
2. In fig2, the calloc function shows "potential overflow due to multiplication before call to calloc at 00107187" - CWE190, how is this different from 1? They both triggered different sets of errors, why?, I can see some IMUL happening in calloc at 00107187, but why there was no NULL pointer dereference?

Any insights on this would
be so helpful. Thank you!

[Enkelmann]

Regarding 1.: Yes, all warnings of the cwe_checker are only potential bugs, since false positives are almost not avoidable for this type of static analysis. And if I read your code snippet correctly, then your example here is a false positive, since the analysis checks in line 72 in the decompiler window whether calloc returned a null pointer here.

Regarding 2.: The IMUL instruction triggered the CWE190 warning, which also looks like a false positive. Actually, this might be a case where the current master branch of the cwe_checker does not produce a false positive here, since we now check whether we can statically ensure that only small integers got multiplied. But the analysis should also generate a CWE-476 Null Pointer Dereference warning at the same address. At least if the shown decompiler snippet is correct there is no Null check here. Can you check that with the command line output of the cwe_checker? The corresponding Ghidra EOL comment in your screenshot may have been overwritten by the CWE-190 warning at the same address.

[Enkelmann]

Well, the CWE-476 check only looks for unchecked return values of function calls that may return null pointers. Your example does not contain such a function call, thus it cannot find this type of Null dereference.

If I read your example correctly, the Null pointer comes from a parameter to the function itself that may be a Null pointer, right? In theory we could improve the CWE-476 check to also find these kinds of Null dereferences. That would depend on the Memory check being precise enough to tell us when a pointer parameter could be a Null pointer. I would have to thoroughly test that, because if it is not yet precise enough for that we would only generate lots of false positives.

[Enkelmann]

Why the previous example is not identified as a possible Null dereference is unclear to me. I think I would have to debug the binary in question to find the cause for that. Could very well be a bug in the CWE-476 check.

[anzosasuke]

Thanks @Enkelmann. Here is the binary if you'd like to find the bug
mcf_s.zip

function name:primal_net_simplex

[anzosasuke]

Here I have another example which is different from above, I think.
This is the source code

Cwe_checker do not find this as well. Why is it so?(I am definitely not trying to criticize. It's for my Research.). As always, I am grateful for your insights.
here is in ghidra.

[Enkelmann]

Regarding the mcf_s binary: I found the reason for the check failing to find the Null dereference: basket is a global variable. Back when I wrote the check it was still very unclear how we wanted to track global variables. Nowadays we have a plan for that, but it is not yet implemented. So back then there was an alternative (and quite hacky) way to track global variables just for this check. But if I remember correctly, it produced too many false positives, so it was disabled again. I will put this on my TODO list for when the check gets reworked (probably as soon as general tracking of global variables is implemented).

Regarding your last example: The CWE-476 check cannot find this kind of Null dereference, since the Null pointer is not a return value of some function call. The Memory check could in theory find this kind of Null dereference, but it tries to be very conservative before flagging something as Null dereference. At the moment it usually flags only cases where some pointer is explicitly set to Null. And since it already produces too many false positives the general analysis quality has to be improved before we try to find more Null dereferences with it.

Long story short: In both cases we need to improve analysis quality before we can track the bug variant without producing too many false positive warnings in the process.