[Date Prev][Date Next] [Chronological] [Thread] [Top]

Calysto v1.5 reports on openldap_v2.4.4alpha

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

        http://www.domagoj.info/
        http://www.calysto.org/