linux-kernel - Re: [PATCH 1/5] string.h: Introduce memtostr() and memtostr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VeOQ+x3WgFeG89X=kGUo=w=ztkdBkA3_K6yy+2mWV83AA@mail.gmail.com>
Date: Wed, 10 Apr 2024 07:08:10 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: "Martin K . Petersen" <martin.petersen@...cle.com>, Justin Stitt <justinstitt@...gle.com>, 
	Andy Shevchenko <andy@...nel.org>, linux-hardening@...r.kernel.org, 
	Charles Bertsch <cbertsch@....net>, Bart Van Assche <bvanassche@....org>, 
	Sathya Prakash <sathya.prakash@...adcom.com>, 
	Sreekanth Reddy <sreekanth.reddy@...adcom.com>, 
	Suganath Prabu Subramani <suganath-prabu.subramani@...adcom.com>, 
	"James E.J. Bottomley" <jejb@...ux.ibm.com>, Kashyap Desai <kashyap.desai@...adcom.com>, 
	Sumit Saxena <sumit.saxena@...adcom.com>, Nilesh Javali <njavali@...vell.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Himanshu Madhani <himanshu.madhani@...cle.com>, 
	linux-kernel@...r.kernel.org, MPT-FusionLinux.pdl@...adcom.com, 
	linux-scsi@...r.kernel.org, mpi3mr-linuxdrv.pdl@...adcom.com, 
	GR-QLogic-Storage-Upstream@...vell.com
Subject: Re: [PATCH 1/5] string.h: Introduce memtostr() and memtostr_pad()

On Wed, Apr 10, 2024 at 5:31 AM Kees Cook <keescook@...omium.org> wrote:
>
> Another ambiguous use of strncpy() is to copy from strings that may not
> be NUL-terminated. These cases depend on having the destination buffer
> be explicitly larger than the source buffer's maximum size, having
> the size of the copy exactly match the source buffer's maximum size,
> and for the destination buffer to get explicitly NUL terminated.
>
> This usually happens when parsing protocols or hardware character arrays
> that are not guaranteed to be NUL-terminated. The code pattern is
> effectively this:
>
>         char dest[sizeof(src) + 1];
>
>         strncpy(dest, src, sizeof(src));
>         dest[sizeof(dest) - 1] = '\0';
>
> In practice it usually looks like:
>
> struct from_hardware {
>         ...
>         char name[HW_NAME_SIZE] __nonstring;
>         ...
> };
>
>         struct from_hardware *p = ...;
>         char name[HW_NAME_SIZE + 1];
>
>         strncpy(name, p->name, HW_NAME_SIZE);
>         name[NW_NAME_SIZE] = '\0';
>
> This cannot be replaced with:
>
>         strscpy(name, p->name, sizeof(name));
>
> because p->name is smaller and not NUL-terminated, so FORTIFY will
> trigger when strnlen(p->name, sizeof(name)) is used. And it cannot be
> replaced with:
>
>         strscpy(name, p->name, sizeof(p->name));
>
> because then "name" may contain a 1 character early truncation of
> p->name.
>
> Provide an unambiguous interface for converting a maybe not-NUL-terminated
> string to a NUL-terminated string, with compile-time buffer size checking
> so that it can never fail at runtime: memtostr() and memtostr_pad(). Also
> add KUnit tests for both.

Obvious question, why can't strscpy() be fixed for this corner case?

-- 
With Best Regards,
Andy Shevchenko