Date: Thu, 15 Sep 2005 08:35:53 +0400 From: Andrey Chernov <ache@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, Trevor Blackwell <tlb@tlb.org> Subject: Re: bin/86135: Fwd: Latent buffer overflow in getcwd Message-ID: <20050915043553.GA26630@nagual.pp.ru> In-Reply-To: <20050915120351.Q43928@delplex.bde.org> References: <1126728802.42486.3239.camel@lab> <20050915120351.Q43928@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 15, 2005 at 01:27:03PM +1000, Bruce Evans wrote:
> MAXPATHLEN is not very relevant here -- the size needed is just the size of
> our buffer, and MAXPATHLEN bytes is neither usually necessary nor always
While it can be so for "up", it is not so for "ep", since it is
filled by __getcwd() syscall and can't be bigger.
Could you consider MAXPATHLEN for "ep" and 1024 for "up" variant?
> - MAXPATHLEN is a misspelling of {PATH_MAX}.
It is BSDsm. getwd(1) refers to MAXPATHLEN too.
> - The magic 340 in the above was (1024 - 4) / strlen("../"). Now its
> magic is deeper. 340 was wrong even when the initial upsize was known
> to be (1024 - 4) since it didn't allow for the NUL terminator or mount
> points. The exact is something like
> 1 + (initial_upsize - {NAME_MAX} - 1) / strlen("../").
Why ever this magic needed? It is only in comment, not in code.
--
http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050915043553.GA26630>