wine 0.9.39: Calysto v1.4 NULL dereference reports

[Domagoj Babic]

Hello,

I finally found time to go through Calysto reports for wine. Here are
the warnings related to applications. For libraries, since Calysto
doesn't know the calling context, any parameter ptr dereference without
checking is considered a bug. We can go over those warnings later if
anyone is really interested.

Here we go:


---------------------------------------------------------------
wine 0.9.39:

Calysto: ??/11

[Please replace ?? with the number of reports that require some
corrective action, adding assertion is considered a corrective action.
For every report, leave + if requires corrective action, replace with -
if it's definitely false positive, and replace with ? if unknown.
For false positives, please provide explanations. For ?, please ask what's
unclear. If you discover new bugs that Calysto should have caught,
please mention that as well.]


*** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_fnt2bdf.bc ***

Possible NULL-ptr deref (vc32):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/fnt2bdf.c:91
+ main (fnt2bdf.c:548) calls return_data_value (@572), passing it a
pointer to &(pTInfo->type_id), which return_data_value dereferences (@91).
pTInfo aliases (lpdata+2), and lpdata was initialized with a call to
get_resource_table (@561), which can set it to NULL (either if malloc
(@534) returns NULL, or if it is set explicitly to NULL (@540)).


*** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_makedep.bc ***

Possible NULL-ptr deref (vc796):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/makedep.c:196
+ Ptr p xmalloc-ed (makedep.c:187) dereferenced. Note that although
xmalloc checks pointer (util.c:31), report(R_FATAL, "msg") does not
exit, but only reports the msg and returns, so p (NULL) will be
still dereferenced.

*** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_sfnt2fnt.bc ***

Possible NULL-ptr deref (vc47):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/sfnt2fnt.c:240
+ malloc-ed ptr eblc dereferenced without checking

Possible NULL-ptr deref (vc58):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/sfnt2fnt.c:321
+ malloc-ed ptr dfCharTable dereferenced without checking

Possible NULL-ptr deref (vc61):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/sfnt2fnt.c:338
+ ptr os2, returned by function FT_Get_Sfnt_Table dereferenced
without checking - I couldn't find the source of that function.


*** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_winebuild_winebuild.bc
***

Possible NULL-ptr deref (vc5400):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/winebuild/import.c:108
+ seems that table->names can be NULL (or unitialized) at this
line if the test @102 is false, and in the following call chain:
main -> parse_options -> add_extra_ld_symbol -> add_name

Possible NULL-ptr deref (vc5868):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/winebuild/import.c:362
+ seems that ignore_symbols.names can be NULL if test @359 is true.


*** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_winedump_winedump.bc
***

Possible NULL-ptr deref (vc11598):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/winedump/main.c:334
+ malloc-ed ptr buf dereferenced without checking

Possible NULL-ptr deref (vc5636):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/winedump/debug.c:687
+ malloc-ed ptr stabbuff dereferenced without checking


*** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_winegcc_winegcc.bc ***

Possible NULL-ptr deref (vc978):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/winegcc/winegcc.c:467
+ ptr output_file, returned from strdup, dereferenced without checking.
strdup can return NULL.

Possible NULL-ptr deref (vc1013):
@/work/benchmarks/SOURCES/wine-0.9.39/tools/winegcc/utils.c:118
+ starray_dup (utils.c:136) initializes dup with strarray_alloc().
strarray_alloc also sets dup->base to NULL. Then strarray_dup calls
strarray_add (@142), passing it a pointer to dup. If the test in
strarray_add (@113) fails, the function dereferences dup->base directly.
---------------------------------------------------------------


Feedback will be appreciated.

I can't do another round of checking before Aug 1, as I'm travelling.
At that point Calysto will have more knowledge about clib functions,
hopefully resulting in more bugs being reported.

Regards,

--
        Domagoj Babic

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