bug-hurd
[Top][All Lists]
Advanced

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

mp4h: Strange? segfault problem


From: Svante Signell
Subject: mp4h: Strange? segfault problem
Date: Wed, 28 Dec 2011 10:17:24 +0100

Hi, 

Something to think about in Christmas/New Year times?

When building mp4h and running the built program on an input file it
segfaults in some cases. For example when creating the documentation
from mp4h.mp4h during the build. Giving the same command two directory
levels higher succeeds!

I found out that the end of the environment vector __environ is
overwritten/truncated somewhere, removing the null termination. Then a
subsequent a call to getenv() makes the program segfault! The problem
is a too short resolvedname vector in builtin.c, see bug #653362. The
segfault happens by running the test program with a long PWD string,
e.g.:

cd .../mp4h/mp4h-1.3.1/src
mkdir a_very_long_pathname_and_even_longer
cd a_very_long_pathname_and_even_longer ../mp4h ../test2.mp4h

I'm attaching the stripped-down test2.mp4h file.

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. 

Anyway, it seems that the realpath() function is not to be trusted with
fixed length vectors, unless the size is PATH_MAX (= 4096) according to
the man page if it is defined. The preferred way of usage seems to be a
resolved_path equal to NULL (or canonicalize_file_name()) or even the
lstat() call.

Attachment: test2.mp4h
Description: Text document


reply via email to

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