From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99A9539184F for ; Thu, 23 Jul 2026 19:28:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784834907; cv=none; b=ktggm/erYxCTKA7wHLwdc+itkIxGRAPTmF/6yEyp9xlf9q9LRwVfUuouRK9e58w81WxvnfIzBsw/M8kcOm3FFkrfRcnVtErr8QvTNxG/1OBmrHX8t+dpNuDMBJx0Agkf6cHRBTVMMLIlk2xgcypk8UjwUMZlCSc2cfMCTazpGII= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784834907; c=relaxed/simple; bh=i60azfLBnSXzNK6t08rfTtxXVGv0I+hjhtmRpzEEhn8=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=uuS5325B4MJ/U4ZmJ7nuHKCYpO0Yl1IeI2empvP5P04CgwkIK9p71voFYDLyCQS0SIWLWsAOJcoyVkMfjn7EJGLS/WZ9PoKTY8bcH1GCfsv2dqud1djBMgBe2OO4KaSLi+X8uLm+RE69a00J3/y6mN8HcxA+4XuRVH4fn/bWP+Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=VHCvzvxT; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="VHCvzvxT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2693F1F000E9; Thu, 23 Jul 2026 19:28:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1784834906; bh=euG2Y4aY51hwbeOmGnI2zs/L3KEz6TRvg4sOXqPLEsM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=VHCvzvxT5droJ24wAZwhS9S5A9GeeouJmGNjKMVPpAX6YA5CutZxXwqr2SMVCnzp3 etwouWbUsLwMtkZ6uINXzmF6khCOrL1kSBOk12S/dy22GxVnBtW/brdrjYfMygoTqB Ewq285H8XMU3SKAQqVa91LpN/Dr/82+0PsqKh4ys= Date: Thu, 23 Jul 2026 12:28:25 -0700 From: Andrew Morton To: Bradley Morgan 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 Message-Id: <20260723122825.4626f7e9efb30b22e2ac9d9b@linux-foundation.org> In-Reply-To: <5CBDF317-FB8B-4569-8B2F-96D350657054@grrlz.net> References: <5CBDF317-FB8B-4569-8B2F-96D350657054@grrlz.net> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 23 Jul 2026 14:04:25 +0100 Bradley Morgan 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.