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 9EA6729405; Fri, 28 Aug 2026 01:59:31 +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=1787882372; cv=none; b=RHmXwl0qpijS7uO7CXP+yfa2iH0sDbkJmabgbBP+k+it1sFK3gca7j4ZB/owxZAf+A3wHkf0k+zAFhz+VqZMH0VLB3IdDJYrKdaBULOOScyP4IjROaDcPbnRNcYyCQEFtcbcrzxaernvOb3TLflVKcRZnY+kolIJKE3qEDGnlI8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787882372; c=relaxed/simple; bh=PLUrSJ7Bgr42fAa7hl3L90oFyHaK/ng3BsHc6DjlYsg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TwH4PczUyFzbig4jJ4R15lEDqRT7s0XuEkzgSiNhR++xtcep4EbhyTT6/6DZ8/lBWJGbpV+eeJ+qvMc8rSalZgS24e/XAMeJqGaVLU4YfIdn78IRQuxn6iUYvKl2m7JQjPj/TqxhKtUbel9vVnIZSCabxidsw0Hr8wo1bVk2rdw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=alyJu5Ry; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="alyJu5Ry" Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id B51761F000E9; Fri, 28 Aug 2026 01:59:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787882371; bh=BmMeT+sGruSoarJZXTMiWDmYAjjQLaM8q39gUOJQkx8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=alyJu5RyJZxHpySxmSX2EQq01LxMYALxg4y2c7/trNsJ8eg1uAVvo3Ay8zeIfizUT a1TZZEP8ghnZT7m+o1kxgQbg+UMP57BmgZEpv7WUkf70OpF5fg0ESZnQWa0dSfLH3n J1wj613i20sY6qEp2Z7S0IdG04bRyXQg7Wug+Q1CJCn99pDT1gX0XFW7cK45t39C3O d/wNvxDqLspl04zBg3cTdxrdZFxU4NbIMxvXoAFGO0TaKV2GVTzWPYEsJUOAruawKe Rl0XgcYaJ+IFN00KAUOzqYTfnOcH/yXW6iCR0sFbrmYwqM6NJsZvIRsV84GIP/yKm6 0+0XXkf3ek2UA== Date: Fri, 28 Aug 2026 04:59:27 +0300 From: Jarkko Sakkinen To: "Cen Zhang (Microsoft Security FORGE Labs)" Cc: Mimi Zohar , David Howells , Paul Moore , James Morris , "Serge E. Hallyn" , Roberto Sassu , David Safford , Greg Kroah-Hartman , Kees Cook , Francis Perron , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Akrites SIRT , AutonomousCodeSecurity@microsoft.com, Cen Zhang Subject: Re: [PATCH v2] KEYS: encrypted: fix integer overflow of datablob_len Message-ID: References: <20260826154456.85974-1-blbllhy@gmail.com> 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-Disposition: inline In-Reply-To: <20260826154456.85974-1-blbllhy@gmail.com> On Wed, Aug 26, 2026 at 11:44:56AM -0400, Cen Zhang (Microsoft Security FORGE Labs) wrote: > From: "Cen Zhang (Microsoft Security FORGE Labs)" > > The datablob_len field in struct encrypted_key_payload and the local > variable in encrypted_key_alloc() are declared as unsigned short, which > has a maximum value of 65535. The datablob_len is computed as: > > format_len + 1 + strlen(master_desc) + 1 + strlen(datalen) + 1 > + ivsize + 1 + encrypted_datalen > > An attacker can create an encrypted key with a very long datalen string > (e.g., 32756 characters of leading zeros followed by "4096", which > kstrtol() happily parses as 4096), and then update it with a very long > master_desc string (~32760 characters). The combined lengths exceed > 65535, causing the unsigned short to silently wrap around. This results Please use concrete sizes as possible. E.g., 16-bit word or u16 would be much less involved than "unsigned short". > in a grossly undersized kzalloc() allocation, and the subsequent > memcpy() in __ekey_init() writes ~32KB past the end of the buffer, > corrupting adjacent slab objects. One more: please describe the issue as ergnomic as possible (but still complete). I care neither Alice nor Bob. > > Fix this by: > 1. Using check_add_overflow() to calculate datablob_len directly into > its existing unsigned short destination. > 2. Checking the total payload length the same way before passing it to > key_payload_reserve(), since key->datalen is also unsigned short. > 3. Using kzalloc_flex() to allocate encrypted_key_payload together with > its trailing payload_data[] array. > > Fixes: 7e70cb497850 ("keys: add new key-type encrypted") > Cc: stable@vger.kernel.org > Assisted-by: GitHub-Copilot:claude-opus-4.6 > Signed-off-by: Cen Zhang (Microsoft Security FORGE Labs) > Signed-off-by: Francis Perron (Akrites SIRT) > --- > Changes in v2: > - Keep datablob_len unchanged and check both unsigned short bounds with > check_add_overflow(). > - Use kzalloc_flex() for the trailing payload_data[] array. > - Correct the attribution and sign-off trailers. > > The initial version was discussed off-list and is not publicly archived. > > security/keys/encrypted-keys/encrypted.c | 20 ++++++++++++++------ > 1 file changed, 14 insertions(+), 6 deletions(-) > > diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c > index 59cb77b237b3..e07092ea301a 100644 > --- a/security/keys/encrypted-keys/encrypted.c > +++ b/security/keys/encrypted-keys/encrypted.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -579,6 +580,7 @@ static struct encrypted_key_payload *encrypted_key_alloc(struct key *key, > { > struct encrypted_key_payload *epayload = NULL; > unsigned short datablob_len; > + unsigned short payload_totallen; > unsigned short decrypted_datalen; > unsigned short payload_datalen; > unsigned int encrypted_datalen; > @@ -632,16 +634,22 @@ static struct encrypted_key_payload *encrypted_key_alloc(struct key *key, > > encrypted_datalen = roundup(decrypted_datalen, blksize); > > - datablob_len = format_len + 1 + strlen(master_desc) + 1 > - + strlen(datalen) + 1 + ivsize + 1 + encrypted_datalen; > + if (check_add_overflow(format_len + 1 + strlen(master_desc) + 1 > + + strlen(datalen) + 1 + ivsize + 1, > + encrypted_datalen, &datablob_len)) > + return ERR_PTR(-EINVAL); > + > + if (check_add_overflow(datablob_len, > + payload_datalen + HASH_SIZE + 1, > + &payload_totallen)) > + return ERR_PTR(-EINVAL); > > - ret = key_payload_reserve(key, payload_datalen + datablob_len > - + HASH_SIZE + 1); > + ret = key_payload_reserve(key, payload_totallen); > if (ret < 0) > return ERR_PTR(ret); > > - epayload = kzalloc(sizeof(*epayload) + payload_datalen + > - datablob_len + HASH_SIZE + 1, GFP_KERNEL); > + epayload = kzalloc_flex(*epayload, payload_data, payload_totallen, > + GFP_KERNEL); > if (!epayload) > return ERR_PTR(-ENOMEM); > > -- > 2.55.0 BR, Jarkko