Throwback to 2015 when one twitter discussion about a dangerous way to use memcmp lead to bug reports in Glibc's memchr, strncat and strnlen implementations.
Conversation
Replying to
The closing argument for the strnlen issue, interpreting the sentence “The strnlen() function shall never examine more than maxlen bytes of the array pointed to by s” as implying that s must be an array of maxlen bytes is some serious throwback. sourceware.org/bugzilla/show_
2
1
2
The Linux kernel has a strscpy function with this issue. It tripped me up when I implemented the Linux kernel CONFIG_FORTIFY_SOURCE. Fixed it a few days later.
Linus didn't understand, seemed to think I was encouraging using strlcpy and got pissed off about it.
1
1
They make strscpy out to be a safer alternative to all the other string functions, but yet strscpy(s, n) is unsafe when even when strcpy would not be unsafe if the destination is smaller than n. It uses that assumption to assume it can clobber unused bytes after the terminator.
1
1
I don't think this is a good thing, but after getting lectured on something I never did, I was discouraged from trying to say anything about it. I didn't bother trying to land the rest of CONFIG_FORTIFY_SOURCE (intra-object checks, alloc_size attributes) upstream either.
This is sad. One can have varied points of view about mitigations that sacrifice 5% speed or memory use in exchange for improved security, but not computing invalid pointers costs nothing.
2
1
I got discouraged from contributing to Linux upstream for other reasons: maintainers incredibly hostile to robustness and security and certain companies treating people contributing to security upstream as their enemies. My out-of-tree slab canary feature led to being accused of
1
Show replies