linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: Yafang Shao <laoar.shao@gmail.com>,
	akpm@linux-foundation.org,  torvalds@linux-foundation.org,
	justinstitt@google.com, ebiederm@xmission.com,
	 alexei.starovoitov@gmail.com, rostedt@goodmis.org,
	catalin.marinas@arm.com,  penguin-kernel@i-love.sakura.ne.jp,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	 linux-trace-kernel@vger.kernel.org, audit@vger.kernel.org,
	linux-security-module@vger.kernel.org,  selinux@vger.kernel.org,
	bpf@vger.kernel.org, netdev@vger.kernel.org,
	 dri-devel@lists.freedesktop.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	 "Gustavo A. R. Silva" <gustavoars@kernel.org>
Subject: Re: [PATCH v7 5/8] mm/util: Fix possible race condition in kstrdup()
Date: Sun, 29 Sep 2024 09:58:24 +0200	[thread overview]
Message-ID: <xzhijtnrz57jxrqoumamxfs3vl7nrsu5qamcjcm4mgtdhruy5r@4az7dbngmfdn> (raw)
In-Reply-To: <202409281414.487BFDAB@keescook>

[-- Attachment #1: Type: text/plain, Size: 3433 bytes --]

[CC += Andy, Gustavo]

On Sat, Sep 28, 2024 at 02:17:30PM GMT, Kees Cook wrote:
> > > diff --git a/mm/util.c b/mm/util.c
> > > index 983baf2bd675..4542d8a800d9 100644
> > > --- a/mm/util.c
> > > +++ b/mm/util.c
> > > @@ -62,8 +62,14 @@ char *kstrdup(const char *s, gfp_t gfp)
> > >  
> > >  	len = strlen(s) + 1;
> > >  	buf = kmalloc_track_caller(len, gfp);
> > > -	if (buf)
> > > +	if (buf) {
> > >  		memcpy(buf, s, len);
> > > +		/* During memcpy(), the string might be updated to a new value,
> > > +		 * which could be longer than the string when strlen() is
> > > +		 * called. Therefore, we need to add a null termimator.
> > > +		 */
> > > +		buf[len - 1] = '\0';
> > > +	}
> > 
> > I would compact the above to:
> > 
> > 	len = strlen(s);
> > 	buf = kmalloc_track_caller(len + 1, gfp);
> > 	if (buf)
> > 		strcpy(mempcpy(buf, s, len), "");
> > 
> > It allows _FORTIFY_SOURCE to track the copy of the NUL, and also uses
> > less screen.  It also has less moving parts.  (You'd need to write a
> > mempcpy() for the kernel, but that's as easy as the following:)
> > 
> > 	#define mempcpy(d, s, n)  (memcpy(d, s, n) + n)
> > 
> > In shadow utils, I did a global replacement of all buf[...] = '\0'; by
> > strcpy(..., "");.  It ends up being optimized by the compiler to the
> > same code (at least in the experiments I did).
> 
> Just to repeat what's already been said: no, please, don't complicate
> this with yet more wrappers. And I really don't want to add more str/mem
> variants -- we're working really hard to _remove_ them. :P

Hi Kees,

I assume by "[no] more str/mem variants" you're referring to mempcpy(3).

mempcpy(3) is a libc function available in several systems (at least
glibc, musl, FreeBSD, and NetBSD).  It's not in POSIX nor in OpenBSD,
but it's relatively widely available.  Availability is probably
pointless to the kernel, but I mention it because it's not something
random I came up with, but rather something that several projects have
found useful.  I find it quite useful to copy the non-zero part of a
string.  See string_copying(7).
<https://www.man7.org/linux/man-pages/man7/string_copying.7.html>

Regarding "we're working really hard to remove them [mem/str wrappers]",
I think it's more like removing those that are prone to misuse, not just
blinly reducing the amount of wrappers.  Some of them are really useful.

I've done a randomized search of kernel code, and found several places
where mempcpy(3) would be useful for simplifying code:

./drivers/staging/rtl8723bs/core/rtw_ap.c:		memcpy(pwps_ie, pwps_ie_src, wps_ielen + 2);
./drivers/staging/rtl8723bs/core/rtw_ap.c-		pwps_ie += (wps_ielen+2);

equivalent to:

	pwps_ie = mempcpy(pwps_ie, pwps_ie_src, wps_ielen + 2);

./drivers/staging/rtl8723bs/core/rtw_ap.c:		memcpy(supportRate + supportRateNum, p + 2, ie_len);
./drivers/staging/rtl8723bs/core/rtw_ap.c-		supportRateNum += ie_len;

equivalent to:

	supportRateNum = mempcpy(supportRate + supportRateNum, p + 2, ie_len);

./drivers/staging/rtl8723bs/core/rtw_ap.c:		memcpy(dst_ie, &tim_bitmap_le, 2);
./drivers/staging/rtl8723bs/core/rtw_ap.c-		dst_ie += 2;

equivalent to:

	dst_ie = mempcpy(dst_ie, &tim_bitmap_le, 2);


And there are many cases like this.  Using mempcpy(3) would make this
pattern less repetitive.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-09-29  7:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-17  2:56 [PATCH v7 0/8] Improve the copy of task comm Yafang Shao
2024-08-17  2:56 ` [PATCH v7 1/8] Get rid of __get_task_comm() Yafang Shao
2024-08-17  2:56 ` [PATCH v7 2/8] auditsc: Replace memcpy() with strscpy() Yafang Shao
2024-08-17  2:56 ` [PATCH v7 3/8] security: Replace memcpy() with get_task_comm() Yafang Shao
2024-08-17  2:56 ` [PATCH v7 4/8] bpftool: Ensure task comm is always NUL-terminated Yafang Shao
2024-08-17  8:38   ` Alejandro Colomar
2024-08-18  2:27     ` Yafang Shao
2024-08-18  8:25       ` Alejandro Colomar
2024-08-17  2:56 ` [PATCH v7 5/8] mm/util: Fix possible race condition in kstrdup() Yafang Shao
2024-08-17  8:48   ` Alejandro Colomar
2024-08-17 16:26     ` Linus Torvalds
2024-08-17 17:03       ` Alejandro Colomar
2024-09-28 21:17     ` Kees Cook
2024-09-29  7:58       ` Alejandro Colomar [this message]
2024-09-29  9:48         ` Alejandro Colomar
2024-09-26 17:35   ` Andy Shevchenko
2024-09-27  8:57     ` Yafang Shao
2024-09-28 21:14   ` Kees Cook
2024-08-17  2:56 ` [PATCH v7 6/8] mm/util: Deduplicate code in {kstrdup,kstrndup,kmemdup_nul} Yafang Shao
2024-08-17  8:57   ` Alejandro Colomar
2024-08-17  9:05     ` Alejandro Colomar
2024-08-26  9:20     ` Alejandro Colomar
2024-08-26 13:13       ` Yafang Shao
2024-08-17  2:56 ` [PATCH v7 7/8] net: Replace strcpy() with strscpy() Yafang Shao
2024-08-17  2:56 ` [PATCH v7 8/8] drm: " Yafang Shao
2024-08-26  2:30 ` [PATCH v7 0/8] Improve the copy of task comm Yafang Shao
2024-08-28  1:19   ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xzhijtnrz57jxrqoumamxfs3vl7nrsu5qamcjcm4mgtdhruy5r@4az7dbngmfdn \
    --to=alx@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=audit@vger.kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ebiederm@xmission.com \
    --cc=gustavoars@kernel.org \
    --cc=justinstitt@google.com \
    --cc=kees@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=rostedt@goodmis.org \
    --cc=selinux@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox