> Date: Fri, 3 Jan 2025 14:07:17 +0100 > From: Roland Illig <roland.il...@gmx.de> > > These code snippets made me wonder whether strncpy should be banned from > kernel code, in order to force developers to think about properly > handling character arrays and strings.
We have seen attempts to systematically eradicate strncpy, e.g. by replacing it by strlcpy. The result is almost always two new classes of bugs: 1. reading off the end of the input because strlcpy requires the input to be a NUL-terminated string of arbitrary length, not limited by the length argument; and 2. leaking kernel memory garbage into userland, because strlcpy does not fully initialize the output buffer like strncpy. Previous discussion about strlcpy and better handling of truncation: https://mail-index.netbsd.org/tech-security/2020/02/08/msg001046.html The response can't just be `ban strncpy' or `ban strlcpy'. Developers will reach for something else, and whatever they reach for has to serve their needs well, and do so succinctly, or else it will just introduce new varieties of bugs that are just as hard to audit. So any proposal needs to have alternatives, and a systematic study of how the existing idioms and call sites are better served by these alternatives.
