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@FreeBSD.org
          Reporter: jan.kokemuel...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Reply via email to