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