git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Prevent buffer overflows when path is too big

From
Torsten Bögershausen <tboegi@web.de>
Date
Oct 20, 2013, 06:27 UTC
Message-ID
<526377C1.8020907@web.de>
In-Reply-To
<20131020060517.GA8436@domone.podge>
On 20.10.13 08:05, Ondřej Bílka wrote:
Show 24 quoted lines
> On Sun, Oct 20, 2013 at 07:47:06AM +0200, Torsten Bögershausen wrote:
>> (may be s/path is too big/path is too long/ ?)
>>
>> On 19.10.13 12:52, Antoine Pelisse wrote:
>>> Currently, most buffers created with PATH_MAX length, are not checked
>>> when being written, and can overflow if PATH_MAX is not big enough to
>>> hold the path.
>>>
>>> Fix that by using strlcpy() where strcpy() was used, and also run some
>>> extra checks when copy is done with memcpy().
>>>
>>> Reported-by: Wataru Noguchi <wnoguchi.0727@gmail.com>
>>> Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
>>> ---
>>> diff --git a/abspath.c b/abspath.c
>>> index 64adbe2..0e60ba4 100644
>>> --- a/abspath.c
>>> +++ b/abspath.c
>>> @@ -216,11 +216,15 @@ const char *absolute_path(const char *path)
>>>  const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
>>>  {
>>>  	static char path[PATH_MAX];
> 
> Why do you need static there?

Good point. get_pathname() from path.c may be better.

Show 21 quoted lines
>>> +
>>> +	if (pfx_len > PATH_MAX)
>> I think this should be 
>> if (pfx_len > PATH_MAX-1) /* Keep 1 char for '\0'
>>> +		die("Too long prefix path: %s", pfx);
>>> +
>>>  #ifndef GIT_WINDOWS_NATIVE
>>>  	if (!pfx_len || is_absolute_path(arg))
>>>  		return arg;
>>>  	memcpy(path, pfx, pfx_len);
>>> -	strcpy(path + pfx_len, arg);
>>> +	strlcpy(path + pfx_len, arg, PATH_MAX - pfx_len);
>>
>> I'm not sure how to handle overlong path in general, there are several ways:
>> a) Silently overwrite memory (with help of memcpy() and/or strcpy()
>> b) Silently shorten the path using strlcpy() instead of strcpy()
>> c) Avoid the overwriting and call die().
>> d) Prepare a longer buffer using xmalloc()
>>
> There is also
> e) modify allocation to place write protected page after buffer end.
Yes, I think this is what electric fence, DUMA or valgrind do:

http://sourceforge.jp/projects/freshmeat_efence/ http://duma.sourceforge.net/ http://valgrind.sourceforge.net/

Theses are very good tools for developers, finding memory corruption (or other bugs like using uninitialized memory).

One of the motivation I asked for test cases is that a git developer can run these test cases under valgrind and can verify that we are never out of range.

For an end user a git "crash" caused by trying to write to a write protected page is better than silently corrupting memory.

And a range check, followed by die(), is even easier to debug. For an end user. /Torsten

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Previous: Ondřej BílkaNext: Ondřej Bílka
Message 16 of 44 in “mingw-multibyte: fix memory acces violation and path length limits.”
  1. mingw-multibyte: fix memory acces violation and path length limits.Wataru Noguchi, Sep 28, 2013
  2. Johannes SchindelinSep 28, 2013
  3. Wataru NoguchiSep 29, 2013
  4. Stefan BellerSep 29, 2013
  5. Wataru NoguchiOct 1, 2013
  6. René ScharfeSep 30, 2013
  7. Erik Faye-LundSep 30, 2013
  8. Wataru NoguchiOct 1, 2013
  9. Wataru NoguchiOct 2, 2013
  10. Antoine PelisseOct 3, 2013
  11. Erik Faye-LundOct 3, 2013
  12. Wataru NoguchiOct 5, 2013
  13. Prevent buffer overflows when path is too bigAntoine Pelisse, Oct 19, 2013
  14. Torsten BögershausenOct 20, 2013
  15. Ondřej BílkaOct 20, 2013
  16. Torsten BögershausenOct 20, 2013
  17. Ondřej BílkaOct 20, 2013
  18. Duy NguyenOct 20, 2013
  19. Antoine PelisseOct 20, 2013
  20. Duy NguyenOct 21, 2013
  21. Johannes SixtOct 21, 2013
  22. Erik Faye-LundOct 21, 2013
  23. Jeff KingOct 21, 2013
  24. Jeff KingOct 21, 2013
  25. 1/2 entry.c: convert checkout_entry to use strbufNguyễn Thái Ngọc Duy, Oct 23, 2013
  26. 2/2 entry.c: convert write_entry to use strbufNguyễn Thái Ngọc Duy, Oct 23, 2013
  27. Junio C HamanoOct 23, 2013
  28. Duy NguyenOct 24, 2013
  29. Junio C HamanoOct 24, 2013
  30. Duy NguyenOct 24, 2013
  31. Antoine PelisseOct 23, 2013
  32. Duy NguyenOct 23, 2013
  33. Antoine PelisseOct 23, 2013
  34. Jeff KingOct 23, 2013
  35. Erik Faye-LundOct 23, 2013
  36. Jeff KingOct 23, 2013
  37. Junio C HamanoOct 23, 2013
  38. Jeff KingOct 23, 2013
  39. entry.c: convert checkout_entry to use strbufNguyễn Thái Ngọc Duy, Oct 24, 2013
  40. Duy NguyenOct 23, 2013
  41. Prevent buffer overflows when path is too longAntoine Pelisse, Nov 26, 2013
  42. Junio C HamanoNov 26, 2013
  43. Antoine PelisseNov 29, 2013
  44. Prevent buffer overflows when path is too longAntoine Pelisse, Dec 14, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.