MantisBT - CMake
View Issue Details
0011018CMakeCMakepublic2010-07-21 08:252011-05-02 14:45
Petr Uzel 
Ben Boeckel 
highmajoralways
closedfixed 
CMake-2-8 
CMake 2.8.4CMake 2.8.4 
0011018: CMake compilation fails with buffer overflow detected
SystemInformationImplementation::ChipID.ProcessorName buffer is to short so that it cannot store long enough processor name.

This leads to buffer overflow in
Source/kwsys/SystemInformation.cxx:2040-2042.

[cmake-2.8.2]

I suggest to increase the CHIPNAME_STRING_LENGTH to some higher value. Patch attached.
No tags attached.
has duplicate 0009267closed Bill Hoffman Buffer overflows in SystemInformation.cxx 
diff fortify-buffer-overflows.diff (506) 2010-07-21 08:25
https://public.kitware.com/Bug/file/3257/fortify-buffer-overflows.diff
Issue History
2010-07-21 08:25Petr UzelNew Issue
2010-07-21 08:25Petr UzelFile Added: fortify-buffer-overflows.diff
2010-07-21 10:28Bill HoffmanStatusnew => assigned
2010-07-21 10:28Bill HoffmanAssigned To => David Cole
2010-09-09 17:48David ColePrioritynormal => high
2010-09-09 17:50David ColeNote Added: 0022171
2010-09-16 05:52Petr UzelNote Added: 0022255
2010-09-16 07:16David ColeAssigned ToDavid Cole => Bill Hoffman
2010-11-04 17:10David ColeTarget Version => CMake 2.8.4
2010-12-08 13:36Ben BoeckelAssigned ToBill Hoffman => Ben Boeckel
2010-12-08 13:37Ben BoeckelNote Added: 0023807
2010-12-08 17:40Ben BoeckelNote Added: 0023828
2010-12-21 08:27Brad KingNote Added: 0024307
2011-01-06 14:42Ben BoeckelNote Added: 0024474
2011-01-06 14:42Ben BoeckelStatusassigned => resolved
2011-01-06 14:42Ben BoeckelResolutionopen => fixed
2011-01-06 14:42Ben BoeckelFixed in Version => CMake 2.8.4
2011-02-03 18:53David ColeRelationship addedhas duplicate 0009267
2011-05-02 14:45David ColeNote Added: 0026318
2011-05-02 14:45David ColeStatusresolved => closed

Notes
(0022171)
David Cole   
2010-09-09 17:50   
How do you reproduce this problem?

There's actually a processor name string longer than 48 chars out there in the wild?
What is it?

And is 70 sufficiently future proof? (Is there a max reasonable agreed-upon-by-vendors length for this...?)
(0022255)
Petr Uzel   
2010-09-16 05:52   
Hello David,

> How do you reproduce this problem?
By building cmake-2.8.2 with g++-4.5 with following options:
-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables

> There's actually a processor name string longer than 48 chars out there in
> the wild? What is it?
The strings come from cmake sources. See Source/kwsys/SystemInformation.cxx, lines 2040-2042 (in cmake-2.8.2)
(0023807)
Ben Boeckel   
2010-12-08 13:37   
I think it'd be saner to use snprintf where possible here to avoid future overflows. A size of 70 should be good for now, but protecting against future overflows should be done as well IMO. I'll work to get this merged for 2.8.4.
(0023828)
Ben Boeckel   
2010-12-08 17:40   
I changed things to be std::string instead to avoid all future issues with buffer overflows with these variables. Since it changes kwsys, I can't push it right now. Will get it merged this week if possible.
(0024307)
Brad King   
2010-12-21 08:27   
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c88a862 [^]
(0024474)
Ben Boeckel   
2011-01-06 14:42   
Committed to master.

http://cmake.org/gitweb?p=cmake.git;a=commit;h=4c88a8622dd25bc3d630f2d35e3a4acca9a7a5a2 [^]
(0026318)
David Cole   
2011-05-02 14:45   
Closing resolved issues that have not been updated in more than 3 months.