[Mono-bugs] [Bug 82678][Maj] Changed - Mono_Posix_Syscall_readdir_r causes stack corruption in readdir_r, resulting in crash

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by jonpryor at vt.edu.

http://bugzilla.ximian.com/show_bug.cgi?id=82678

--- shadow/82678	2007-09-04 06:03:37.000000000 -0400
+++ shadow/82678.tmp.15178	2007-09-04 07:56:17.000000000 -0400
@@ -178,6 +178,34 @@
 clear that readdir_r() is a flawed interface. Could an alternative
 implementation be to use readdir() while performing locking ourselves?
 
 Also, thanks for pointing out the alignment problem in the proposed
 solution. 
 
+
+------- Additional Comments From jonpryor at vt.edu  2007-09-04 07:56 -------
+Indeed, the Solaris readdir_r() man page states (
+http://docs.sun.com/app/docs/doc/816-5168/6mbb3hrpg?a=view):
+
+"The caller must allocate storage pointed to by entry to be large
+enough for a dirent structure with an array of char d_name member
+containing at least NAME_MAX (that is, pathconf(directory,
+_PC_NAME_MAX)) plus one elements. (_PC_NAME_MAX is defined in
+<unistd.h>.)"
+
+It's _still_ horribly broken, but apparently something like the
+original patch must be done. :-/
+
+As for using readdir() instead of readdir_r()...  Does that actually
+work?  Trying it as a test case would be an interesting observation
+(e.g. see how  readdir() handles a 4096-character filename, assuming
+your filesystem supports it).  I'm not too keen on making readdir()
+thread-safe, though, as I've been trying to keep all locking in
+Mono.Posix.dll instead of in MonoPosixHelper.  (In which case the
+"solution" is to just make Mono.Posix.dll use Syscall.readdir()
+instead of Syscall.readdir_r()...)
+
+So if this is the best we can do, which is better: a stack overflow or
+a heap overflow?  The possibility for overflow _still_ exists, so
+we'll have to pick our poison... :-(
+
+