[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mp4h: Strange? segfault problem

From: Svante Signell
Subject: Re: mp4h: Strange? segfault problem
Date: Wed, 28 Dec 2011 11:26:37 +0100

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]