Many but not all calls to strncpy check and stuff in a
null at the end of the strings, but a number do not,
which can cause strings NOT to be null-terminatd.
This causes mysterious errors, usually sigsegv (;-))
This was found by Dieter Jurzitza, initially in
Patches to use strlcpy (the new standard intrface) and strlcat
Created attachment 2070 [details]
Diffs to change strncpy(x,y,z-1) to strlcpy(x,y,z)
Patch one of three, the strncpy calls. To be followed
by strncat->strlcate and optionally sprintf->snprintf.
Created attachment 2071 [details]
Change strncat(x,y,z-1) to strlcat(x,y,z)
Patch 2 of three, strncat.
Created attachment 2072 [details]
Change sprintf(buf,...) to snprintf(buf, sizeof(buf), ...)
And the sprintfs where the write didn't
preallocate the exact right size...
The obligatory caveat: This set of patches should be
applied to a test machine and the full regression test
run, as there is room for a mechanical error on my part
to over-truncate strings being built up from sequences
I was careful, but that's necessary, not sufficient (;-))
The same code appears in samba 4:
strncpy(a,b,n); a[n+1] = NULL;
Any time someone misses the null, or gets the offset wrong,
one gets hard-to-diagnose bugs and runtime crashes.
Should this be submitted as a samba4 bug?
This fix is now out of date: I'll rescan for erronious strncpys, which
can trivially cause buffer overruns. This was first encounte red by Dieter
Jurzitza, in pam/winbind.c