Re: Minor patch to correct buffer overrun

[Chris Sutcliffe]

Hi Paul,

On 16 August 2010 09:32, Paul Smith wrote:
> Are you saying that MinGW defines a MAXPATHLEN that is shorter than the
> real maximum path length on Windows, and that the max path length on
> Windows is really 1024 not 259?  So, this change is a workaround for a
> MinGW system header bug?

No, I didn't explain things well.  MAX_PATH on windows should be 259.

> Or, are you saying that make is using this value incorrectly, and that
> instead of MAXPATHLEN it should be using something else?

Looking at the make source, in particular dir.c, it has (in find_directory()):

        char tem[MAXPATHLEN], *tstart, *tend;

and when running the attached Makefile with make via GDB, make craped
out in the find_directory function.  So based on my findings explained
below, I suspected that MAXPATHLEN was expected to be greater than
259.

> And, I'm not sure what you mean by "make expects 'MAXPATHLEN' to be
> considerably bigger"; in what way does make expect this?  Do you mean
> that in one place make creates a buffer of 1024, and in another place it
> tries to copy it into a buffer that is MAXPATHLEN large?

My debugging process was somewhat convoluted.  Upon discovering that
the original make-3.82 binary I produced for MinGW caused an exception
with the attached Makefile, I re-compiled the binary and did not strip
it (which how I found out about the failure in find_directory()).
Unfortunately doing further debugging with GDB was problematic due to
the optimization (-O2).  I recompiled again without optimization and
did not experience the exception.  Being far from a GDB expert, I was
at a loss as to how to use GDB to debug this issue further (i.e. with
the Optimization enabled).  However, I've seen this type of behaviour
before with pointers addressing memory they shouldn't be.

I was made aware on the MinGW-Users list that when compiled with the
build_w32.bat file, the gnumake.exe produced did not generate the
exception.  Doing a comparison between config.h.W32 and the generated
config.h (via running configure in MSYS), I noticed there were several
differences.  Executing a trial-and-error approach, I found that the
exception occurred if 'HAS_SYS_PARAM_H' was defined.

Looking at MinGW's sys/param.h I saw that MAXPATHLEN was defined as follows:

#define MAXPATHLEN PATH_MAX

where PATH_MAX is defined as 259.  Looking at make.h I saw:

#ifndef MAXPATHLEN
# define MAXPATHLEN 1024
#endif

Given the behaviour I was experiencing (the exception) and seeing the
discrepancy in MAXPATHLEN, I made the minor change:

#ifdef __MINGW32__
# undef MAXPATHLEN
#endif
#ifndef MAXPATHLEN
# define MAXPATHLEN 1024
#endif

Under the assumption that make was expecting MAXPATHLEN to be 1024
(vs. 259).  When I recompiled with this change, I could no longer
re-create the exception.

Please let me know if there is anything more I can do to help.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

Makefile
Description: Binary data