https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219154
--- Comment #5 from commit-h...@freebsd.org --- A commit references this bug: Author: kib Date: Mon May 15 17:14:53 UTC 2017 New revision: 318298 URL: https://svnweb.freebsd.org/changeset/base/318298 Log: Fix several buffer overflows in realpath(3). - The statement "left_len -= s - left;" does not take the slash into account if one was found. This results in the invariant "left[left_len] == '\0'" being violated (and possible buffer overflows). The patch replaces the variable "s" with a size_t "next_token_len" for more clarity. - "slen" from readlink(2) can be 0 when encountering empty symlinks. Then, further down, "symlink[slen - 1]" underflows the buffer. When slen == 0, realpath(3) should probably return ENOENT (http://austingroupbugs.net/view.php?id=825, https://lwn.net/Articles/551224/). Some other minor issues: - The condition "resolved_len >= PATH_MAX" cannot be true. - Similarly, "s - left >= sizeof(next_token)" cannot be true, as long as "sizeof(next_token) >= sizeof(left)". - Return ENAMETOOLONG when a resolved symlink from readlink(2) is too long for the symlink buffer (instead of just truncating it). - "resolved_len > 1" below the call to readlink(2) is always true as "strlcat(resolved, next_token, PATH_MAX);" always results in a string of length > 1. Also, "resolved[resolved_len - 1] = '\0';" is not needed; there can never be a trailing slash here. - The truncation check for "strlcat(symlink, left, sizeof(symlink));" should be against "sizeof(symlink)" (the third argument to strlcat) instead of "sizeof(left)". Submitted by: Jan Kokem??ller <jan.kokemuel...@gmail.com> PR: 219154 MFC after: 2 weeks Changes: head/lib/libc/stdlib/realpath.c -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
