On Wed, 2011-12-28 at 10:33 +0100, Samuel Thibault wrote: > Svante Signell, le Wed 28 Dec 2011 10:17:24 +0100, a écrit : > > On GNU/Linux shortening the resolvedname vector from PATH_MAX to 64 > > results in a stack corruption. This is not nice, but since that vector > > is allocated on the stack, maybe it is more acceptable than an > > environment corruption. > > Well, this is not surprising to get crashes when cheating with PATH_MAX: > the kernel still thinks PATH_MAX is 4096, and thus thinks that the > buffer is actually 4096 bytes long, and thus happily overwrites whatever > is after it if userland doesn't make it so.
Ok, this comparison was maybe not the best. The main problem remains, for Hurd, how can a too short path string overwrite the environment vector of strings? I tried to find instances where __environment is used/set and found only references to eglibc, not gnumach or hurd. I also compiled a version of libc with printf statements and used gdb, but nothing usable showed yet. I will try to create a shorter test case than the whole mp4h executable. Any hints on where to look for further debugging?
