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 a much larger size than that. In function check_file_link (src/pacman/check.c), the length of a symbolic link is used in a variable length array: char link[length]; // length being st->st_size + 1 This doesn't just allow a very theoretical overflow on 32 bit systems with 64 bit off_t (which is st_size's type), it can also overflow available stack space, leading to a segmentation fault. Symbolic links pointing to something that is longer than PATH_MAX can be considered illegal, so just get a fixed size array and reject symbolic links which are longer than that. --- src/pacman/check.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/pacman/check.c b/src/pacman/check.c index d282cc2..6e8cda7 100644 --- a/src/pacman/check.c +++ b/src/pacman/check.c @@ -132,15 +132,16 @@ static int check_file_time(const char *pkgname, const char *filepath, static int check_file_link(const char *pkgname, const char *filepath, struct stat *st, struct archive_entry *entry) { - size_t length = st->st_size + 1; - char link[length]; + ssize_t len; + char link[PATH_MAX]; - if(readlink(filepath, link, length) != st->st_size) { + len = readlink(filepath, link, sizeof(link)); + if (len == -1 || len >= PATH_MAX) { /* this should not happen */ pm_printf(ALPM_LOG_ERROR, _("unable to read symlink contents: %s\n"), filepath); return 1; } - link[length - 1] = '\0'; + link[len] = '\0'; if(strcmp(link, archive_entry_symlink(entry)) != 0) { if(!config->quiet) { -- 2.8.3