[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] "buffer overflow detected" error on fedora distributions.


In my opinion, the problem here is that the FORTIFY_SOURCE code is simply 
broken and it should be fixed or turned off.  Bacula does far more checking 
on internal buffers than glibc does, so I see no reason to have 

The solution is to turn it off.  We don't use FORTIFY_SOURCE in any of our 
testing, so turning it on only increases your changes of unexpected and 
unwanted failures especially considering that the current FORTIFY_SOURCE 
detects an overflow that does not exist ...

Please note that this "problem" has been submitted as a bug report #1042, to 
which I have given roughly the same response.

Unfortunately, the solution you propose needlessly consumes extra space and is 
not guaranteed to resolve the problem in the case the union becomes larger 
than the size you have specified.

Best regards,


On Tuesday 29 January 2008 00.02:45 Michael Lausch wrote:
> The error is due to the new (well ~ core 5) buffer overflow checking
> implemented by gcc and glibc. _FORTIFY_SOURCE=2  activates it. what
> happens can be read in detail at
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html. but basically
> the error is a buffer overflow check in parse.c in the bacula library.
> In this file the following definition can be found:
> extern  CURES res_all;
> CURES is a type defined in the library with a size of, let's say 120
> bytes. the actual value is not important.
> In the bat module for example, the res_all variable is redefined as
> URES res_all;
> in bat_conf.cpp. URES is a type with, let's say, 250 bytes. The actual
> value is not important as long as it's larger then the size of the URES
> type defined in the library. The variable res_all_size is initialized to
> the size of the res_all variable, in my example to 250.
> In the init_resource() function in parse_conf.c is a call to
> memset(&res_all, 0, res_all_size);
> This call is replaced to a boundary checking memset() call as outlined
> by the example 2 in
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html
> The 3rd parameter of the memset call, res_all_size, which is 250, is
> checked against the size of the CURES type (120) and the buffer overflow
> error is raised by the boundary check of the memset function.
> The solution is to allocate the res_all variable dynamically.
> My quick hack solution was to change the definition of CURES to
> union CURES {
>    MSGS  res_msgs;
>    RES hdr;
>    char _space_[1024];
> };
> This makes the size of the CURES union larger than all the other unions
> defined in the different bacula executables and the memset check
> succeeds. But as i said this is a hack and i used it only as a band aid
> to get a runnable system.
> The solution to disable boundary checking by using a D_FORTIFY_SOURCE=0
> definition in the compiler command line should not be done, because
> checking for errors in such a sensible application as a backup utility
> is always a good thing.

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.