Message ID | ZR9l446ndB4n1Xl4@gondor.apana.org.au |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a888:0:b0:403:3b70:6f57 with SMTP id x8csp29326vqo; Thu, 5 Oct 2023 18:42:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEh/xf1FrFGgFBrajqBquTNTobZXILjZ4Slc1+U8NK9aqfcDfXtgG6Ugbz83jLDmi2k7fqk X-Received: by 2002:a17:902:e547:b0:1c7:56d8:9068 with SMTP id n7-20020a170902e54700b001c756d89068mr7383904plf.31.1696556536708; Thu, 05 Oct 2023 18:42:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696556536; cv=none; d=google.com; s=arc-20160816; b=eCIhxsbkc+SB8LffbUG4pY7G61BjAT3qhsSZ1iD4hIt4v1wrhXxoXcC2RgU+yy0jE4 L56uIYOlIYL793+GvNYV4KyZnGm22a3SapZ7+oLogmdsL6SvXA4ihSFFxNmDequ2SFw1 rsxtpsfun4c2Xzsn9WjoGw+FYYeb+/bfJCo6pr3i23D8D085fH1UEnMGJorc3+Fd61qz 3N8OXFzpkDDR93siXEmJz4ph8Sif9Qdhj55+I85hw+XyZiJjBOVycjsUuZRrhchoh3Zu lTmhKY7RQx8JtNQkmn2ziMUq02PS0EAd+XS5IpSEynvwyiN0UyKc/B0NHo458W0vWaHg Jkcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=6k+s2oh77h0Lck0WE4j7ys6Xh0pI4zuk5HzNsmyPJ88=; fh=2JgU+FP391bnUkQBxfCY4DB4fED79it/pD39D5OPqi4=; b=ad54mtLYLy7NPvKbbfdJBBPaBwsfd1jFEZq9Ysab7yVg50s9OzpGFS4AaekX/yXS8o f7vQjzSus5+LaXnupy32PBd/+tWXSoylqS9w/w2Z5KU5zNwrfe0fSR+jVMj+jTP5QtqQ T7GjXMNTvqvzQAR8iRdVy14Nkze8T3ARp688MsODTEQB6rpFEDKEz9YPdksIOg65xGBH Pa5p9Y6jmsz8fLvQu1NqU3jdvL/PVBbBwAOIw6/BZacdlmV2e01QWASRM/xZdwgVz5Bd vtemmrqZmM1fDJukOlWlMzMEna1diugJbubj1f2POxEIux1gvHj6/E4tSdL1iWknV6ir iQRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id k12-20020a170902c40c00b001c7352c5482si2954156plk.373.2023.10.05.18.42.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Oct 2023 18:42:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id F0BF8837725F; Thu, 5 Oct 2023 18:42:10 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229693AbjJFBmA (ORCPT <rfc822;ezelljr.billy@gmail.com> + 18 others); Thu, 5 Oct 2023 21:42:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229666AbjJFBl6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 5 Oct 2023 21:41:58 -0400 Received: from abb.hmeau.com (abb.hmeau.com [144.6.53.87]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3785BE7; Thu, 5 Oct 2023 18:41:57 -0700 (PDT) Received: from loth.rohan.me.apana.org.au ([192.168.167.2]) by formenos.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1qoZqh-0043of-2s; Fri, 06 Oct 2023 09:41:52 +0800 Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Fri, 06 Oct 2023 09:41:55 +0800 Date: Fri, 6 Oct 2023 09:41:55 +0800 From: Herbert Xu <herbert@gondor.apana.org.au> To: Bagas Sanjaya <bagasdotme@gmail.com>, Linux Crypto Mailing List <linux-crypto@vger.kernel.org> Cc: Tatu =?iso-8859-1?q?Heikkil=E4?= <tatu.heikkila@gmail.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Device Mapper <dm-devel@redhat.com>, Mike Snitzer <snitzer@kernel.org>, Alasdair Kergon <agk@redhat.com>, Linux Regressions <regressions@lists.linux.dev> Subject: [PATCH] dm crypt: Fix reqsize in crypt_iv_eboiv_gen Message-ID: <ZR9l446ndB4n1Xl4@gondor.apana.org.au> References: <f1b8d8f5-2079-537e-9d0f-d58da166fe50@gmail.com> <ZR9dEiXhQv-wBVA2@debian.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <ZR9dEiXhQv-wBVA2@debian.me> X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 05 Oct 2023 18:42:11 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778968466983726157 X-GMAIL-MSGID: 1778968466983726157 |
Series |
dm crypt: Fix reqsize in crypt_iv_eboiv_gen
|
|
Commit Message
Herbert Xu
Oct. 6, 2023, 1:41 a.m. UTC
On Fri, Oct 06, 2023 at 08:04:18AM +0700, Bagas Sanjaya wrote: > > > Git bisect lead me to: > > # first bad commit: [e3023094dffb41540330fb0c74cd3a019cd525c2] dm crypt: > > Avoid using MAX_CIPHER_BLOCKSIZE > > > > If I git revert e3023094dffb41540330fb0c74cd3a019cd525c2 on current Linus' > > git master, the issue goes away. So I'm personally not all that affected > > anymore (if I'm ready to compile my kernels from now on), and I understand > > that you have no clear way to reproduce this as it seems strongly bound to > > hardware, but seems like this could point to a potentially serious security > > issue since it involves both crypto and undefined behaviour. Thanks for the report. Sorry this is indeed my fault. The allocated buffer is too small as it's missing the size for the request object itself. Mike, would you be OK with me picking this fix up and pushing it to Linus? Cheers, ---8<--- A skcipher_request object is made up of struct skcipher_request followed by a variable-sized trailer. The allocation of the skcipher_request and IV in crypt_iv_eboiv_gen is missing the memory for struct skcipher_request. Fix it by adding it to reqsize. Fixes: e3023094dffb ("dm crypt: Avoid using MAX_CIPHER_BLOCKSIZE") Reported-by: Tatu Heikkil� <tatu.heikkila@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Comments
On Thu, Oct 05 2023 at 9:41P -0400, Herbert Xu <herbert@gondor.apana.org.au> wrote: > On Fri, Oct 06, 2023 at 08:04:18AM +0700, Bagas Sanjaya wrote: > > > > > Git bisect lead me to: > > > # first bad commit: [e3023094dffb41540330fb0c74cd3a019cd525c2] dm crypt: > > > Avoid using MAX_CIPHER_BLOCKSIZE > > > > > > If I git revert e3023094dffb41540330fb0c74cd3a019cd525c2 on current Linus' > > > git master, the issue goes away. So I'm personally not all that affected > > > anymore (if I'm ready to compile my kernels from now on), and I understand > > > that you have no clear way to reproduce this as it seems strongly bound to > > > hardware, but seems like this could point to a potentially serious security > > > issue since it involves both crypto and undefined behaviour. > > Thanks for the report. Sorry this is indeed my fault. The allocated > buffer is too small as it's missing the size for the request object > itself. > > Mike, would you be OK with me picking this fix up and pushing it to > Linus? > > Cheers, > > ---8<--- > A skcipher_request object is made up of struct skcipher_request > followed by a variable-sized trailer. The allocation of the > skcipher_request and IV in crypt_iv_eboiv_gen is missing the > memory for struct skcipher_request. Fix it by adding it to > reqsize. > > Fixes: e3023094dffb ("dm crypt: Avoid using MAX_CIPHER_BLOCKSIZE") > Reported-by: Tatu Heikkil� <tatu.heikkila@gmail.com> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > index f2662c21a6df..5315fd261c23 100644 > --- a/drivers/md/dm-crypt.c > +++ b/drivers/md/dm-crypt.c > @@ -753,7 +753,8 @@ static int crypt_iv_eboiv_gen(struct crypt_config *cc, u8 *iv, > int err; > u8 *buf; > > - reqsize = ALIGN(crypto_skcipher_reqsize(tfm), __alignof__(__le64)); > + reqsize = sizeof(*req) + crypto_skcipher_reqsize(tfm); > + reqsize = ALIGN(reqsize, __alignof__(__le64)); > > req = kmalloc(reqsize + cc->iv_size, GFP_NOIO); > if (!req) Sure, please do. Shouldn't your header Cc: stable given that the Fixes commit implies v6.5 needs this fix? (sorry I missed this the first time I 'Reviewed-by' the original commit) Reviewed-by: Mike Mike Snitzer <snitzer@kernel.org> Thanks, Mike
On Thu, Oct 05, 2023 at 10:26:14PM -0400, Mike Snitzer wrote: > > Sure, please do. Shouldn't your header Cc: stable given that the > Fixes commit implies v6.5 needs this fix? Sure I'll add it although it will be picked up automatically due to the Fixes header. I'll also fix the reporter's name. > Reviewed-by: Mike Mike Snitzer <snitzer@kernel.org> Thanks!
Linux regression tracking (Thorsten Leemhuis)
Oct. 6, 2023, 8:20 a.m. UTC |
#3
Addressed
Unaddressed
On 06.10.23 04:33, Herbert Xu wrote: > On Thu, Oct 05, 2023 at 10:26:14PM -0400, Mike Snitzer wrote: BTW, Herbert, thx for taking care of this quickly! >> Sure, please do. Shouldn't your header Cc: stable given that the >> Fixes commit implies v6.5 needs this fix? > > Sure I'll add it although it will be picked up automatically due > to the Fixes header. FWIW, as some people don't know this: that might be the case, but there is no guarantee, hence it's better to add it: https://lore.kernel.org/all/2023060703-colony-shakily-3514@gregkh/ > I'll also fix the reporter's name. Side note: a Link: or Closes: tag to the report (https://lore.kernel.org/all/f1b8d8f5-2079-537e-9d0f-d58da166fe50@gmail.com/ ) would be nice as well. Thx again. Ciao, Thorsten
On Fri, Oct 06, 2023 at 09:41:55 +0800, Herbert Xu wrote: > > On Fri, Oct 06, 2023 at 08:04:18AM +0700, Bagas Sanjaya wrote: > > > > > Git bisect lead me to: > > > # first bad commit: [e3023094dffb41540330fb0c74cd3a019cd525c2] dm crypt: > > > Avoid using MAX_CIPHER_BLOCKSIZE > > > > > > If I git revert e3023094dffb41540330fb0c74cd3a019cd525c2 on current Linus' > > > git master, the issue goes away. So I'm personally not all that affected > > > anymore (if I'm ready to compile my kernels from now on), and I understand > > > that you have no clear way to reproduce this as it seems strongly bound to > > > hardware, but seems like this could point to a potentially serious security > > > issue since it involves both crypto and undefined behaviour. > > Thanks for the report. Sorry this is indeed my fault. The allocated > buffer is too small as it's missing the size for the request object > itself. Thank you for your prompt fix, I can access the volume without issue now. :-) -Tatu
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index f2662c21a6df..5315fd261c23 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -753,7 +753,8 @@ static int crypt_iv_eboiv_gen(struct crypt_config *cc, u8 *iv, int err; u8 *buf; - reqsize = ALIGN(crypto_skcipher_reqsize(tfm), __alignof__(__le64)); + reqsize = sizeof(*req) + crypto_skcipher_reqsize(tfm); + reqsize = ALIGN(reqsize, __alignof__(__le64)); req = kmalloc(reqsize + cc->iv_size, GFP_NOIO); if (!req)