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

[Tobias Stoeckmann]

On Thu, Jun 09, 2016 at 04:25:36PM -0400, Andrew Gregory wrote:
> SIZE_MAX is the maximum size of individual objects, not the entire
> addressable space.

I hope you know that it becomes very very theoretical now, and that there
is no such system out there...

Let's assume that there is a system in which size_t is just 16 bit. And
let's further assume that your pointers are still 32 or 64 bit, giving
you an address space for many many size_t-sized objects.

sizeof(size_t) = 2
sizeof(void *) = 8

Do you realize that it means that you have to check every single
occurrence of "size_t len = strlen(x) + 1" for a realistically possible
overflow? And that pacman doesn't do that just like no other sane
software, e.g. OpenSSH, because there's no such system out there?

You would even have to be very careful about pointer arithmetic, because
it further means that

sizeof(size_t) = 2
sizeof(ptrdiff_t) = 8

So even forget about "size_t len = endptr - baseptr". Granted, that kind
of code is "buggy" for that reason, but if we go that far, all our
software is screwed today. And if sizeof(int) eventually turns 8, we
have a real issue to think about.

If this theoretical thing is of interest, we can further discuss this.
But I would prefer to get back into reality. Maybe we are, but in that
case we should boot up a system which has these weird settings. And for
that, I need a name. It's clearly not OS X, *BSD, or Linux. As pacman
is a software that targets Linux (as far as I know, it even has *BSD
support in a few parts), which has a PATH_MAX = 4096 limitation, this
is of no concern for pacman.

On the other hand, broken filesystems are out there. I've created an
image to verify this. In case you need to see the segmentation fault on
your own, I can prepare a fitting package for it and give you
instructions on how to trigger it.


Tobias