Re: [BUG] taskstats: REGISTER_CPUMASK silently truncates the last byte of the cpumask string

[Bradley Morgan]

On 23 July 2026 20:28:25 BST, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
wrote:
>On Thu, 23 Jul 2026 14:04:25 +0100 Bradley Morgan <include@xxxxxxxxx>
>wrote:
>
>> Hi Andrew,
>> 
>> I dont think this actually fixes it... :(
>> 
>
>Thanks.  Obviously I did't try very hard.
>
>> 
>> > -	data = kmalloc(len, GFP_KERNEL);
>> > +	data = kmalloc(len + 1, GFP_KERNEL);
>> >  	if (!data)
>> >  		return -ENOMEM;
>> >  	nla_strscpy(data, na, len);
>> 
>> nla_strscpy() copies at most dstsize - 1 bytes, and dstsize is still
>> len here. When the attr payload comes in without a trailing NUL,
>> srclen == len >= dstsize and the last byte still gets cut off. The
>> bigger buffer just adds a byte nothing ever writes to (the zero pad
>> in nla_strscpy() only goes up to dstsize).
>> 
>> Olegs report even spells this out in its suggested fix direction:
>> allocate len + 1 *and* pass len + 1 as dstsize. The patch only
>> picked up the first half. The fix is something like:
>> 
>> 	data = kmalloc(len + 1, GFP_KERNEL);
>> 	if (!data)
>> 		return -ENOMEM;
>> 	nla_strscpy(data, na, len + 1);
>> 
>> or skip the dance entirely, nla_strdup() already does exactly this:
>> 
>> 	data = nla_strdup(na, GFP_KERNEL);
>> 	if (!data)
>> 		return -ENOMEM;
>> 
>> Btw the bug only bites when the sender doesnt NUL terminate the
>> attr payload; senders that include the NUL (srclen gets decremented
>> for the trailing NUL, so srclen < dstsize) were always fine. Thats
>> probably why this survived 20 years. Might be worth a line in
>> the changelog. And as the report already notes, the policy is
>> NLA_STRING, not NLA_NUL_STRING, so a payload without the trailing
>> NUL is legit input here.
>
>OK, I'll drop this.  Please send along a fix sometime.
>


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