[Bug 206648] Fix double strlen in ktrstruct

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue Jan 26 17:45:35 UTC 2016


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

Mateusz Guzik <mjg at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjg at FreeBSD.org

--- Comment #2 from Mateusz Guzik <mjg at FreeBSD.org> ---
The code is fine correctness-wise, although indeed could be improved by getting
rid of double strlen, I'll maybe commit that later.

If you make changes you would like to submit, please make actual patches (diff
-u, svn diff, git diff, whatever).

Now to the point:
buflen = strlen(name) + 1 datalen;                   
buf = malloc(buflen, M_KTRACE, M_WAITOK);
strcpy(buf, name);
bcopy(data, buf + strlen(name) + 1, datalen);

The claim is that calling strlen twice would be problematic if the string could
change.

First of all, if that was really the case, we would run into trouble with
strcpy. Further, if it could change, maybe it also could be freed?

Clearly, the kernel code needs to ensure the stability of the string. If it is
assumed the string is not going to change, the code is perfectly fine, although
somewhat inefficient.

If the string is in kernel memory and can change, appropriate locks need to be
held across the call. If it is in user memory, it has to be brought in with
things like copyin().

Regardless, I see no bug nor an insecure practice here. If one was to not trust
anything, it would be impossible to implement stuff.

That said thanks for bringing this up, that strlen would really use getting rid
of, but there is nothing to fix correctness-wise or even in the spirit of
defensive programming. One could consider adding an assertion the buffer
belongs to the kernel, but then why would this function be special.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list