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

[Andrew Gregory]

On 06/06/16 at 08:27pm, Tobias Stoeckmann wrote:
> 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. :)

What about simply using a predetermined buffer length?  PATH_MAX isn't
really the right size to use for this anyway, which is why POSIX
defines SYMLINK_MAX.  Since alpm's maximum path length is 1024, using
a buffer size of 2048 or 4096 leaves plenty of room for symlinks to
point to any alpm-managed file (assuming the link doesn't do anything
bizarre like repeat "./" thousands of times).  There could be valid
symlinks that point to non-managed files that we won't be able to
read, but that appears to be the case no matter what we do.

apg