On Mon, Jan 12, 2026 at 02:22:38PM +0100, Borislav Petkov wrote: > On Mon, Jan 12, 2026 at 08:22:36PM +0800, Fushuai Wang wrote: > > > strncpy_from_user() succeeds even if userspace data does not contain a > > > nul. Then it reads length bytes. > > > > Yes, but if there is no NUL byte in the user buf, whether you use > > strncpy_from_user() or copy_from_user(), you need to manually add > > a '\0' in the kernel buf to ensure it is properly NUL-terminated. > > This looks like a bunch of churn to save a "= \0" line. > > The more important question, IMO, would be whether there are cases in the > kernel which *miss* a NUL termination, audit them and fix them. > > That'll give you a better idea whether such a *_nul() helper is even needed. > > Because converting only a handful of obvious places in the face of thousands > of copy_from_user() invocations in the kernel is not doing anything useful.
I'm getting the impression that strncpy_from_user() is the real problem here. It should append a nul byte. That would also be a lot less error-prone than the suggested new API. Requiring a length of N+1 is not the most immediately-obvious API. Alice
