Hi,
I ran my static checker Calysto on openldap v2.4.4alpha. Here are the results.
Could you please check them out and replace ??? with Yes/No, and if it's a false positive, write a short explanation.
calysto v1.5 on openldap_v2.4.4alpha: ??/20
*** Analyzing clients_tools_ldapcompare.bc *** ------------------------------------------ Possible NULL-ptr deref (vc148): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1334 Bug: ??? Explanation: ber_strdup call (common.c:734) can return NULL, which is dereferenced in strlen call (@742) ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc162): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:921 Bug: No Explanation: Pointer arithmetic + lazy summary expansion ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc192): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:846 Bug: ??? Explanation: ber_strdup call (ldapcompare.c:136) can return NULL, which is dereferenced in strchr call on the next line. ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc209): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/sasl.c:53 Bug: ??? Explanation: lutil_sasl_defaults call (@common.c:1060) can return NULL, which is passed to lutil_sasl_freedefs (@1071), which dereferences it (@sasl.c:53). ------------------------------------------
*** Analyzing clients_tools_ldapmodify.bc *** ------------------------------------------ Possible NULL-ptr deref (vc1789): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1909 Bug: ??? Explanation: ber_strdup call (@fetch.c:62) can return NULL, which is dereferenced by fopen (@65). ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc1791): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/ldif.c:868 Bug: ??? Explanation: ber_memalloc call (@ldif.c:867) can return NULL, which is dereferenced on the next line. ------------------------------------------
*** Analyzing clients_tools_ldapsearch.bc *** ------------------------------------------ Possible NULL-ptr deref (vc3851): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:157 Bug: ??? Explanation: ldap_parse_reference call (@ldapsearch.c:1394) calls ldap_pvt_get_controls (@references.c:116), which can set ctrls[i]->ldctl_value.bv_val to NULL and return LDAP_SUCCESS. Later, in the call chain: tool_print_ctrls (@ldapsearc.c:1411) -> lutil_b64_ntop (@common.c:1636) ctrls[i]->ldctl_value.bv_val is received as parameter src, which is dereferenced @base64.c:157. If it helps, my trace says that the first test (@129) fails and that the value of ctrls[i]->ldctl_value.bv_len is 1. Don't know if that's relevant or not. ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc3852): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:178 Bug: ??? Explanation: ber_memalloc call (@common.c:1634) can return NULL, which is passed to lutil_b64_ntop (@1636), which dereferences it @base64.c:178. ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc3853): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:130 Bug: ??? Explanation: Seems like a duplicate of vc3851, but according to this trace, it seems that src can be uninitialized. ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc3929): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:922 Bug: ??? Explanation: Seems like ctrls[i]->ldctl_oid, dereferenced @common.c:1671) can be uninitialized. ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc4342): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/ldif.c:718 Bug: No Explanation: pointer arithmetic + lazy summary expansion ------------------------------------------
*** Analyzing libraries_liblber_etest.bc *** ------------------------------------------ Possible NULL-ptr deref (vc7): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:212 Bug: ??? Explanation: getbuf call (@etest.c:151) can return NULL, which atoi dereferences on the next line. ------------------------------------------
*** Analyzing libraries_libldap_ltest.bc *** ------------------------------------------ Possible NULL-ptr deref (vc44): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/libldap/test.c:778 Bug: ??? Explanation: Seems like vals[i]->bv_val can remain uninitialized. ------------------------------------------
*** Analyzing libraries_librewrite_rewrite.bc *** ------------------------------------------ Possible NULL-ptr deref (vc4622): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/avl.c:289 Bug: ??? Explanation: It seems that rewrite_info_init @rewrite.c:52 call can return a valid info, but leave info->li_params->avl_link[0] uninitialized. info is then passed to rewrite_read @54, which passes it to rewrite_parse @parse.c:112, which passes it to rewrite_param_set @config.c:283, which passes &info->li_params to rewrite_var_insert_f @params.c:51 (received as pointer tree). p is initialized with *tree @190. If nside==0, p->avl_link[0] is dereferenced @289. Note that Calysto finds _a trace_, not _the shortest_ trace. So, perhaps this would fail sooner.
Related problem: rewrite_info_init call @rewrite.c:52 can return NULL, which is then passed to rewrite_read @54, which calls rewrite_parse @parse.c:112. rewrite_parse has an assertion that will fail @config.c:59. The pointer returned by rewrite_info_init should be checked right away, and if NULL exit with an appropriate msg. ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc4626): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/avl.c:308 Bug: ??? Explanation: Seems like r->avl_link can be NULL. Trace is equally long to vc4622, but the control flow context is somewhat more complicated, so I'm leaving that out. ------------------------------------------
*** Analyzing servers_slurpd_slurpd.bc *** ------------------------------------------ Possible NULL-ptr deref (vc216): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:869 Bug: ??? Explanation: CATLINE(buf) is called @config.c:427, but it can fail to initialize line. The trace shows that lcur+len+1 can result in an integer overflow, in which case the test @403 would fail, and line would not be initialized. Later, line is dereferenced @445. ------------------------------------------
*** Analyzing tests_progs_slapd-bind.bc *** ------------------------------------------ Possible NULL-ptr deref (vc27): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-common.c:176 Bug: ??? Explanation: ldap_str2charray call (@slapd-common.c:174) can return NULL, which is dereferenced two lines lower. ------------------------------------------
*** Analyzing tests_progs_slapd-tester.bc *** ------------------------------------------ Possible NULL-ptr deref (vc59): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:277 Bug: ??? Explanation: ldap_str2charray call (@slapd-tester.c:275) can return NULL, which is dereferenced two lines lower. ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc62): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:224 Bug: ??? Explanation: ldap_str2charray call (@slapd-tester.c:218) can return NULL, which is dereferenced @224. ------------------------------------------
------------------------------------------ Possible NULL-ptr deref (vc64): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:226 Bug: ??? Explanation: calloc call (@slapd-tester.c:225) can return a NULL pointer, which is dereferenced on the next line. ------------------------------------------
Thx,
-- Domagoj Babic