From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bmailout1.hostsharing.net (bmailout1.hostsharing.net [83.223.95.100]) (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 804EF1BD9F0; Sun, 12 Oct 2025 07:38:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=83.223.95.100 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760254729; cv=none; b=SpXnyZMEjJWrBakCw0JrVhkirVzj8m4UdeEZ4hQ9X+4wzd2fHsxMl/ECGuEmxXi/oRTTIdHa8pLv/5qKBkE/l8JvLNohkpHLP1PA563MNaI5vRGuypebE7whYya/9PiXnq2PPaTJMJjgw2Og53rv9SP63xws90pZF2Li4FfK+RM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760254729; c=relaxed/simple; bh=B6TTQY2b105FO3hvPVhRwnkmJUx6GedqVg3l81uMnnE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hzMPnDuuAhBWlzwi7d/CLrBAECIpVTLhIkLKwBYmj8SQ4/HGW1Gtwjws9d1/QmFRzAZSEz8sjcMzss0GMoLF/miEL2S/DWiAuTsv8tvW3Cv6wNDCmARvoju0DWyP+0aRq6U/ukJ4DLwTdohBjvHc2lqWIYkOrvUHcQm2AUrLsQQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de; spf=none smtp.mailfrom=h08.hostsharing.net; arc=none smtp.client-ip=83.223.95.100 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=h08.hostsharing.net Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id AB6DD2C048AF; Sun, 12 Oct 2025 09:38:44 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 97ADB4A12; Sun, 12 Oct 2025 09:38:44 +0200 (CEST) Date: Sun, 12 Oct 2025 09:38:44 +0200 From: Lukas Wunner To: Thorsten Blum Cc: David Howells , Ignat Korchagin , Herbert Xu , "David S. Miller" , keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Message-ID: References: <20251007185220.234611-2-thorsten.blum@linux.dev> 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: <20251007185220.234611-2-thorsten.blum@linux.dev> On Tue, Oct 07, 2025 at 08:52:20PM +0200, Thorsten Blum wrote: > +++ b/crypto/asymmetric_keys/asymmetric_type.c > @@ -141,12 +142,13 @@ struct asymmetric_key_id *asymmetric_key_generate_id(const void *val_1, > size_t len_2) > { > struct asymmetric_key_id *kid; > + size_t len; > > - kid = kmalloc(sizeof(struct asymmetric_key_id) + len_1 + len_2, > - GFP_KERNEL); > + len = size_add(len_1, len_2); > + kid = kmalloc(struct_size(kid, data, len), GFP_KERNEL); > if (!kid) > return ERR_PTR(-ENOMEM); This should error out on overflow, rather than continuing with a SIZE_MAX length. So how about using check_add_overflow() instead of size_add() and returning -EOVERFLOW if that returns true? asymmetric_key_generate_id() is invoked, among other things, with the raw serial number from the X.509 certificate, which is an ASN.1 INTEGER, which can be arbitrarily large. (You may want to mention that in the commit message.) So checking for overflows does seem to make sense to guard against maliciously crafted certificates. Thanks, Lukas