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 pam/winbind.c, Patches to use strlcpy (the new standard intrface) and strlcat follow. --dave
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 of strlcpy/strlcat. I was careful, but that's necessary, not sufficient (;-)) --dave
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? --dave
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 --dave