mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Bradley Morgan <include@grrlz.net>
Cc: oleg.deomi@gmail.com, bsingharora@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: [BUG] taskstats: REGISTER_CPUMASK silently truncates the last byte of the cpumask string
Date: Thu, 23 Jul 2026 16:17:09 -0700	[thread overview]
Message-ID: <20260723161709.1312af98b9ad71762257a15a@linux-foundation.org> (raw)
In-Reply-To: <EC49FE41-7F5F-41E0-A07A-ABEB8ECA514D@grrlz.net>

On Thu, 23 Jul 2026 22:11:43 +0100 Bradley Morgan <include@grrlz.net> wrote:

>...
>
> Hi Andrew, let me be honest, I CBA to do a new thread, here's my suggestion

Seems this fooled Sashiko, so no AI review for you!

> From: Bradley Morgan <include@grrlz.net>
> Date: Thu, 23 Jul 2026 21:09:22 +0000
> Subject: [PATCH] taskstats: fix cpumask parsing cutting off the last character
> 
> parse() hands nla_strscpy() len as dstsize, and nla_strscpy() copies
> at most dstsize - 1 bytes. When the attr payload comes in without a
> trailing NUL, srclen == len >= dstsize and the last character of the
> cpumask string gets cut off. Register "0-15" and you are silently
> listening on "0-1", exit data for the rest never shows up.
> 
> The bug only bites when the sender doesnt NUL terminate the payload;
> senders that include the NUL were always fine (srclen gets decremented
> for the trailing NUL, so srclen < dstsize). Thats probably why this
> survived 20 years. And the policy is NLA_STRING, not NLA_NUL_STRING,
> so a payload without the trailing NUL is legit input here.
> 
> Skip the kmalloc/nla_strscpy dance entirely and use nla_strdup(),
> which already allocates srclen + 1 and terminates. The nla_len()
> bounds checks stay as they were.
> 
> ...
>
> --- a/kernel/taskstats.c
> +++ b/kernel/taskstats.c
> @@ -371,10 +371,9 @@ static int parse(struct nlattr *na, struct cpumask *mask)
>  		return -E2BIG;
>  	if (len < 1)
>  		return -EINVAL;
> -	data = kmalloc(len, GFP_KERNEL);
> +	data = nla_strdup(na, GFP_KERNEL);
>  	if (!data)
>  		return -ENOMEM;
> -	nla_strscpy(data, na, len);
>  	ret = cpulist_parse(data, mask);
>  	kfree(data);
>  	return ret;

Nice, thanks,  There's a nla_strdup(), who knew?

(nla_strdup() could use kstrdup(), btw?)

  reply	other threads:[~2026-07-23 23:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21 12:52 Oleg Deomi
2026-07-21 23:38 ` Andrew Morton
2026-07-23 13:04 ` Bradley Morgan
2026-07-23 19:28   ` Andrew Morton
2026-07-23 21:11     ` Bradley Morgan
2026-07-23 23:17       ` Andrew Morton [this message]
2026-07-23 23:19         ` Bradley Morgan
2026-07-24 15:32         ` Bradley Morgan

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=20260723161709.1312af98b9ad71762257a15a@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=bsingharora@gmail.com \
    --cc=include@grrlz.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg.deomi@gmail.com \
    /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

all inboxes | Powered by JetHome®