[pacman-dev] [PATCH] Prevent stack overflow on symbolic link access.

[Tobias Stoeckmann]

On Mon, Jun 06, 2016 at 01:27:52AM -0400, Andrew Gregory wrote:
> Since we're already talking about unlikely scenarios...  My reading of
> readlink(2) and readlink(3p) suggest this might still run into
> problems on oddly configured systems.  POSIX leaves up to the
> implementation what happens if bufsize > SSIZE_MAX and nothing
> guarantees that PATH_MAX is less than SSIZE_MAX.  

That is true, in fact we would have to check if PATH_MAX is defined
at all. If it's not there, we actually would have to call path_conf
to figure it out. And even then it might be -1 to show that we really
have no limits at all.

But on the bright side, "currently" this is proven by reality to be
no issue, after all nobody filed a bug report for his system, that
pacman does not compile. ;)

Same goes for PATH_MAX being larger than SSIZE_MAX. As long as we can
trust the system that SSIZE_MAX really states the largest value for
an ssize_t and that it has the same size like size_t, we would have
run out of stack space looong before even reaching this function
call.

If I wouldn't have been able to trigger a segfault with an adjusted
file system, I would have skipped sending this patch for being just
a bad fairy tale. But a crashing pacman on a broken file system
sounds worse than a system with such a PATH_MAX -- and that still
wants to use pacman. :)