[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 bugzilla-daemon at bugzilla.ximian.com
Tue Sep 4 07:56:17 EDT 2007

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.


--- 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
+------- Additional Comments From jonpryor at vt.edu  2007-09-04 07:56 -------
+Indeed, the Solaris readdir_r() man page states (
+"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
+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... :-(

More information about the mono-bugs mailing list