On 07/06/16 04:29, Tobias Stoeckmann wrote:
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.
According to gnulib, buggy file systems can report garbage in st_size, so there is no benefit in checking length against it.
check.c: In function ‘check_file_link’: check.c:139:28: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] if(length == -1 || length >= sizeof(link)) { ^~ Please test with using "--enable-warningflags" when configuring. A