Bug 338819 – sci-libs/vtk _FORTIFY_SOURCE indicates presence of overflow

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Diego Elio Pettenò (RETIRED) 2010-09-26 16:36:47 UTC]

You're receiving this bug because the package in Summary has produced _FORTIFY_SOURCE related warnings indicating the presence of a sure overflow in a static buffer.

Even though this is not always an indication of a security problem it might even be. So please check this out ASAP.

By the way, _FORTIFY_SOURCE is disabled when you disable optimisation, so don't try finding out the cause using -O0.

Thanks,
Your friendly neighborhood tinderboxer

[Comment 1 Diego Elio Pettenò (RETIRED) 2010-09-26 16:42:45 UTC]

Created attachment 248697 [details]
Build log (compressed)

[Comment 2 François Bissey 2010-09-26 22:15:24 UTC]

Thanks for the report. The attached log has been gzipped twice (but has only one .gz extension) which lead to some confusion for a few minutes here. Is it a problem with your automated script?

I am a bit confused about the message:

 * QA Notice: Package has poor programming practices which may compile
 *            fine but exhibit random runtime failures.
 * /usr/include/bits/stdio2.h:35:43: warning: call to int __builtin___sprintf_chk(char*, int, unsigned int, const char*, ...) will always overflow destination buffer
 * /usr/include/bits/stdio2.h:35:43: warning: call to int __builtin___sprintf_chk(char*, int, unsigned int, const char*, ...) will always overflow destination buffer
 * /usr/include/bits/stdio2.h:35:43: warning: call to int __builtin___sprintf_chk(char*, int, unsigned int, const char*, ...) will always overflow destination buffer

I was expecting to be directed to some files in the vtk sources, instead
I am directed to a file belonging to glibc. Does this means that the function
provided by this header is misused and I should track it down or is this more subtle?

[Comment 3 Diego Elio Pettenò (RETIRED) 2010-09-26 22:20:07 UTC]

The double-encoding looks like a Bugzilla problem, as the original on my system looks okay… but whatever, since they are going to change it sometime soon one hopes.

As for the warnings, look for the correspondent warnings during the build phase and it'll show where it is being called, Portage only copies the warning call that is tied to the inline functions within the headers, which I admit is quite puzzling the first times.

[Comment 4 François Bissey 2010-09-27 00:34:30 UTC]

(In reply to comment #3)
> The double-encoding looks like a Bugzilla problem, as the original on my system
> looks okay… but whatever, since they are going to change it sometime soon one
> hopes.
> 
> As for the warnings, look for the correspondent warnings during the build phase
> and it'll show where it is being called, Portage only copies the warning call
> that is tied to the inline functions within the headers, which I admit is quite
> puzzling the first times.
> 
Thanks for the info. Found the problem, I will report on the vtk mailing list, patch to follow. I will check the internal copy of vtk in paraview-3.8.0 (science overlay only) later.

[Comment 5 François Bissey 2010-09-27 00:51:25 UTC]

Created attachment 248726 [details, diff]
patch for the vtk-5.6.0-r2 ebuild

Ok the easiest way is just to add a bit of sed in the ebuild.
On line 166 of Utilities/kwsys/SystemInformation.cxx
We have the following definition:
    char ProcessorName[CHIPNAME_STRING_LENGTH];
And CHIPNAME_STRING_LENGTH is defined in turn on line 155 as having a value
of 49+1 (presumably because sometimes there is a white space at the end of the string. The lines singled out by Diego's report try to put strings of length
58, 62 and 55 in there. These are all definitions for Pentium III processors so it is unlikely to happen on halfway modern hardware. 
I set the value at 79+1 to have some margin.

[Comment 6 Justin Lecher (RETIRED) 2011-04-16 10:40:19 UTC]

Thanks for the patch, inlcuded for 5.6.*