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?)
next prev parent 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®