[Bug 219154] [PATCH] buffer overflows in realpath(3)
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon May 8 22:22:54 UTC 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219154
Bug ID: 219154
Summary: [PATCH] buffer overflows in realpath(3)
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: patch
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs at FreeBSD.org
Reporter: jan.kokemueller at gmail.com
Keywords: patch
Created attachment 182421
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=182421&action=edit
fixes for realpath(3)
There are some buffer overflows in realpath(3). The attached patch fixes them:
- 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)".
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list