[Bug 219154] [PATCH] buffer overflows in realpath(3)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219154

--- Comment #5 from commit-hook at 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.kokemueller at 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.