On Fri, Dec 25, 2015 at 8:21 PM, Ricardo Mestre <[email protected]> wrote:
> I made an inspection on userland tree and there quite a few applications still
> using strncpy(3) instead of strlcpy(3). Some of them may never need that
> safety
> since the boundaries are always fixed, nevertheless since strlcpy is a drop-in
> replacement it doesn't hurt to use, plus it will always be safer than strncpy.
strlcpy() is not a "drop-in replacement" for strncpy() for _all_
circumstances. There are conditions under which strncpy()'s behavior
is actually the expected and required. For example, to quote
utmp(5)'s CAVEATS section:
The strings in the utmp and lastlog structures are not normal `C' strings
and are thus not guaranteed to be null terminated.
The practice for those fields is to use strncpy() when filling them,
both so that you don't leak garbage into bytes after the first NUL and
to permit use of the full field width. Switching to strlcpy() would
be wrong for both reasons.
Those are true of some kernel APIs too, thus explaining why the kernel
uses strncpy() in some places.
These calls have been audited before. While it's possible some bogus
strncpy() has crawled back in, a careful review of the context of the
usage is necessary to understand whether the code needs either
a) guaranteed NUL fill, or
b) NUL-less full field fill,
or both.
Losing the former can be a security hole if the data crosses a
security boundary!
Philip Guenther
