utils: Don't let ssize_t overflow when reading very large files

[smcv]

The size to be allocated is tracked as ssize_t, so if it's larger than this, doubling it would cause a signed overflow.

Limiting the data we will read into memory to SSIZE_MAX/2 still lets it occupy 25% of addressable memory (1 GiB on 32-bit or some very large amount on 64-bit), which should be adequate. In practice we expect this function to read a few KiB at most.

In practice we're likely to run out of memory before reaching this point; changing this to SSIZE_MAX / 8, compiling as 32-bit and running ${builddir}/bwrap --args 0 < /dev/zero is a convenient way to test this code path.

Fixes: 422c078 "Check for allocation size overflows"

/cc @cgzones

[smcv]

@cgwalters @alexlarsson: any chance of a review on this? I would really prefer to avoid bubblewrap getting into a situation where my changes can't get reviewed because I'm the only active reviewer.

In general, I would like some help from other maintainers of this project. I'm doing my best to keep it afloat, but my best is not enough: I hope it's already become obvious that having me as the only one doing releases doesn't scale (see also: dbus), and I just don't have the in-depth syscall-level knowledge to assess whether some of the other PRs would be creating security vulnerabilities.

[cgzones]

The condition is indeed wrong.

[smcv]

I'm going to merge this based on @cgzones' non-maintainer review. Please revert if you disagree.

[cgwalters]

I think this looks right. That said, there is now increasing usage of __builtin_mul_overflow in C projects (e.g. Linux wraps it as check_mul_overflow) for similar situations.

[cgwalters]

@cgwalters @alexlarsson: any chance of a review on this? I would really prefer to avoid bubblewrap getting into a situation where my changes can't get reviewed because I'm the only active reviewer.

I'm still around and yeah, it's OK to ping for things like this. Thanks so much for your work!