[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260112132238.GDaWT1ntPxY8VD1hlH@fat_crate.local>
Date: Mon, 12 Jan 2026 14:22:38 +0100
From: Borislav Petkov <bp@...en8.de>
To: Fushuai Wang <fushuai.wang@...ux.dev>
Cc: aliceryhl@...gle.com, akpm@...ux-foundation.org, brauner@...nel.org,
cyphar@...har.com, dave.hansen@...ux.intel.com, hpa@...or.com,
jack@...e.cz, kees@...nel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, luto@...nel.org,
mathieu.desnoyers@...icios.com, mhiramat@...nel.org,
mingo@...hat.com, peterz@...radead.org, rostedt@...dmis.org,
tglx@...nel.org, vmalik@...hat.com, wangfushuai@...du.com,
x86@...nel.org, yury.norov@...il.com
Subject: Re: [PATCH v2 1/6] uaccess: Add copy_from_user_nul helper
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.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists