Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 338819 - sci-libs/vtk _FORTIFY_SOURCE indicates presence of overflow
Summary: sci-libs/vtk _FORTIFY_SOURCE indicates presence of overflow
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Markus Dittrich (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: fortify-source
  Show dependency tree
 
Reported: 2010-09-26 16:36 UTC by Diego Elio Pettenò (RETIRED)
Modified: 2011-04-16 10:40 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Build log (compressed) (vtk-5.6.0-r2:20100925-204943.log.gz,272.23 KB, application/gzip)
2010-09-26 16:42 UTC, Diego Elio Pettenò (RETIRED)
Details
patch for the vtk-5.6.0-r2 ebuild (vtk-ebuild.patch,700 bytes, patch)
2010-09-27 00:51 UTC, François Bissey
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Elio Pettenò (RETIRED) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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 gentoo-dev 2011-04-16 10:40:19 UTC
Thanks for the patch, inlcuded for 5.6.*