The parser in alpm_extract_keyid does not properly check boundaries,
which makes it vulnerable to malicious input for out ouf bondary reads.
I did not attach a proof of concept for this one, because it is very
system-specific if you see a segmentation fault or not. If in doubt,
you won't notice it.
It is possible (but unlikely) to encounter very long symbolic
links, which would take a few mega bytes in size. In general,
such long symbolic links are impossible to create because the
kernel will only accept up to PATH_MAX in length. BUT lstat()
on a maliciously modified symbolic link can return
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
Some resources (memory or file descriptors) are not released on all
error paths.
Signed-off-by: Tobias Stoeckmann
---
Thanks for your valueable review, Andrew. :)
---
lib/libalpm/add.c| 5 -
lib/libalpm/backup.c | 5 +++--
lib/libalpm/be_local.c | 19 ---
lib/
Signature files larger than INT_MAX are already suspicious,
but if they are larger than SIZE_MAX, this code couldn't even
copy them into memory, accepting them as "blank" files at worst.
While adding the INT_MAX check, I also rearranged the code to
avoid a quite harmless TOCTOU race condition betw
