- 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.kokemueller@gmail.com>
PR: 219154
MFC after: 2 weeks
f81e5b2d9b