> My initial patch used strlcpy there, because I wasn't aware of strscpy > before it was suggested: > > http://www.openwall.com/lists/kernel-hardening/2017/05/04/11 > > I was wrong to move it to strscpy. It could be switched back to > strlcpy > again unless the kernel considers the count parameter to be a > guarantee > that could be leveraged in the future. Using the fortified strlen + > memcpy would provide the improvement that strscpy was meant to provide > there over strlcpy. Similarly, the FORTIFY_SOURCE strcat uses strlcat with the assumption that the count parameter is a limit, not a guarantee for a optimization. There's only a C implementation and it currently doesn't, but if it's meant to be a guarantee then the strcat needs to be changed too. I'll make a fix moving away both from the existing functions.
