wine 0.9.39: Calysto v1.4 NULL dereference reports
dank06 at kegel.com
Sun Jul 1 08:50:40 CDT 2007
Those seem to all be build-time tools, where problems are not very critical.
On 7/1/07, Domagoj Babic <babic.domagoj at gmail.com> wrote:
> 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):
> + 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):
> + 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):
> + malloc-ed ptr eblc dereferenced without checking
> Possible NULL-ptr deref (vc58):
> + malloc-ed ptr dfCharTable dereferenced without checking
> Possible NULL-ptr deref (vc61):
> + 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):
> + 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):
> + 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):
> + malloc-ed ptr buf dereferenced without checking
> Possible NULL-ptr deref (vc5636):
> + malloc-ed ptr stabbuff dereferenced without checking
> *** Analyzing /work/benchmarks/BINARY/wine_v0.9.39/tools_winegcc_winegcc.bc ***
> Possible NULL-ptr deref (vc978):
> + ptr output_file, returned from strdup, dereferenced without checking.
> strdup can return NULL.
> Possible NULL-ptr deref (vc1013):
> + 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.
> Domagoj Babic
Wine for Windows ISVs: http://kegel.com/wine/isv
More information about the wine-devel