Date: Tue, 8 Aug 2006 14:15:24 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Bruce Evans <bde@zeta.org.au> Cc: Dag-Erling Sm?rgrav <des@des.no>, Marcel Moolenaar <marcel@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/kldxref kldxref.c Message-ID: <20060808101524.GN54416@comp.chem.msu.su> In-Reply-To: <20060807133921.V6590@delplex.bde.org> References: <200608042128.k74LShD7052071@repoman.freebsd.org> <8664h6ci86.fsf@xps.des.no> <20060807133921.V6590@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 07, 2006 at 01:59:30PM +1000, Bruce Evans wrote:
> On Sun, 6 Aug 2006, Dag-Erling [iso-8859-1] Smørgrav wrote:
>
> >Marcel Moolenaar <marcel@FreeBSD.org> writes:
> >> Log:
> >> Fix (static) buffer overflow bug. The dest buffer is of size MAXPATHLEN,
> >> so dest[MAXPATHLEN] falls outside the buffer. This bug corrupted
> >> arenas[0] defined in libc's malloc.c on PowerPC when kldxref is shared,
> >> which triggered a delayed SIGSERV.
> >
> >MAXPATHLEN should be spelled PATH_MAX.
>
> Actually, MAXPATHLEN is better since it is honestly unportable. It works
> on all [Free]BSD systems, while PATH_MAX only works on POSIX systems that
> define it. The correct spelling of PATH_MAX is {PATH_MAX} or:
>
> #if defined(PATH_MAX) && defined(OPTIMIZE_FOR_COMPILE_TIME_CONST_PATH_MAX)
> char buf[PATH_MAX];
> ...
> #else
> long path_max;
>
> path_max = pathconf(pathname_of_interest, _PC_PATH_MAX);
> if (path_max == -1)
> handle_error();
> assert(path_max > 0 && path_max <= SIZE_MAX)
> buf = malloc((size_t)path_max);
> if (buf == NULL)
> handle_allocation_failure();
> ...
> #endif
>
> The correct spelling is too hard to use for simple unportable utilities
> like kldxref.
Just looked what SUSv3 says:
It should be noted, however, that many of the listed limits
are not invariant, and at runtime, the value of the limit
may differ from those given in this header, for the following
reasons:
The limit is pathname-dependent.
The limit differs between the compile and runtime machines.
For these reasons, an application may use the fpathconf(),
pathconf(), and sysconf() functions to determine the actual
value of a limit at runtime.
Therefore using PATH_MAX alone doesn't buy us true portability
within POSIX. Sigh... It seems indeed better to use the good old
non-portable MAXPATHLEN rather than pretend portability falsely.
--
Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060808101524.GN54416>