The semantics of strlcpy and strlcat

Paul Eggert eggert at cs.ucla.edu
Sat Jan 23 11:24:28 UTC 2016


[This message is responding to 
<https://sourceware.org/ml/libc-alpha/2016-01/msg00573.html>. I am removing 
libc-alpha from CC:, and adding inn-workers to CC:, since this message is 
INN-specific rather than being a glibc thing.]

Russ Allbery wrote:
> I'd like to remove them all from INN as well.  Unfortunately, INN is a
> very old code base that's riddled with buffers of fixed size allocated off
> the stack with unclear object lifetimes and no further thought given to
> any form of memory management, which makes it hard to take the approach
> that I'm using with all other software I maintain (switching to asprintf).
> Short of a grand removal of static buffers that's an immense amount of
> work and may not happen for software that's mostly in maintenance mode,
> I'm not sure what the best solution is.  (I stand by my original feeling
> that silent truncation is generally better than silent buffer overflows,
> but that's a little like saying that tuberculosis is better than ebola.)

Looking at INN it appears that strlcpy and strlcat are used as 
belt-and-suspenders copiers -- callers do not check for truncation (except in 
one place, where a caller checks for truncation incorrectly and this apparently 
can lead to buffer overflow -- I just now filed a bug report about that to 
inn-workers).

If so, how about the attached patch? It assumes the fix I sent earlier for the 
truncation bug. The basic idea is that truncations should never occur, but if 
any does occur then it should be caught and logged. I haven't tested this.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: inn1.diff
Type: text/x-diff
Size: 4725 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20160123/7d8ef4ef/attachment.bin>


More information about the inn-workers mailing list