From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 092B9C636D3 for ; Tue, 7 Feb 2023 18:51:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232523AbjBGSvv (ORCPT ); Tue, 7 Feb 2023 13:51:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232361AbjBGSvu (ORCPT ); Tue, 7 Feb 2023 13:51:50 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CE049EF0; Tue, 7 Feb 2023 10:51:49 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B9D586112F; Tue, 7 Feb 2023 18:51:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34265C433EF; Tue, 7 Feb 2023 18:51:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675795908; bh=x0UI86gVTuknlQ58qUTLvMciZe/bE/6g39HHqZCq0K4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VSh5Dyt8xASnmvTydKvQbaFJHbGaq1MUZN0wdEy/DvbasC+0O95aScLPc+6Klyn2c bLz6vOPlX5UKFjct+uvCLhp86OXHdlZPpVqQgrYkimu51YAHILD+cqxvyKhr7J3d/M nqbxe3p3Vx5295uCHBjBlp47OW4aIwk5nY1ESc6NK2c2qx5wqo2p+2hcR65kVen1IY FW6fJjvx/vzksgupXienOhJuoQYRPZRHbu4D0ZygWDJCwF1+YiHzvHIQiWy9Jq58LT 1CQcYb1TQMbYcUV0R2BSzEDllmjW91t3LetazrD8asBbWcH6yyxYmJFefmk99GRAGy qJc4dDpNt9BjQ== Date: Tue, 7 Feb 2023 10:51:46 -0800 From: Jakub Kicinski To: Herbert Xu Cc: Linux Crypto Mailing List , Alasdair Kergon , Mike Snitzer , dm-devel@redhat.com, "David S. Miller" , Eric Dumazet , Paolo Abeni , netdev@vger.kernel.org, Tyler Hicks , ecryptfs@vger.kernel.org, Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , linux-bluetooth@vger.kernel.org, Steffen Klassert , Jon Maloy , Ying Xue , Boris Pismenny , John Fastabend , David Howells , Jarkko Sakkinen , keyrings@vger.kernel.org Subject: Re: [PATCH 0/17] crypto: api - Change completion callback argument to void star Message-ID: <20230207105146.267fc5e8@kernel.org> In-Reply-To: References: <20230206231008.64c822c1@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, 7 Feb 2023 16:03:52 +0800 Herbert Xu wrote: > > Buggy means bug could be hit in real light or buggy == did not use > > the API right? > > Yes this bug is real. If you hit a driver/algorithm that returns > a different request object (of which there are many in the API) then > you will be dereferencing random pointers. Any aes-gcm or chacha-poly implementations which would do that come to mind? I'm asking 'cause we probably want to do stable if we know of a combination which would be broken, or the chances of one existing are high. Otherwise no objections for the patches to go via the crypto tree, there should be no conflicts AFAIK. Feel free to add my ack on the networking changes if needed. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B994CC636D3 for ; Wed, 8 Feb 2023 07:45:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675842327; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=rLsJe8VRTCIQzoD9XvkxzMKqdsAr8GIUhWdZy/vFDf8=; b=ewVJSzaBE5t9zRs7OyVRKIN9YuCNHt37Vz9mdc0N2azrXFJTWKNevAg+UOaC7DxE7PGzVx Lynu+MkmX8KpsL+HyqfRUBQ/JTA6xtidjx6zED6d/Sg8tgXmI1bk17MQKJsWrSNOH8iT0H yIbo1JkvHEVjsIFwY7Zgwsyjc5BKRyQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-93-7ecMLT94MESDnt31irN30g-1; Wed, 08 Feb 2023 02:45:24 -0500 X-MC-Unique: 7ecMLT94MESDnt31irN30g-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 37D5F1C05AED; Wed, 8 Feb 2023 07:45:22 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 24D2F492C3C; Wed, 8 Feb 2023 07:45:22 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 57F8119465B2; Wed, 8 Feb 2023 07:45:21 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id D4CC81946589 for ; Tue, 7 Feb 2023 18:51:52 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id B349F400D9D0; Tue, 7 Feb 2023 18:51:52 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast07.extmail.prod.ext.rdu2.redhat.com [10.11.55.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AC1234024B7C for ; Tue, 7 Feb 2023 18:51:52 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 914603C10681 for ; Tue, 7 Feb 2023 18:51:52 +0000 (UTC) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-322-b6p0KKQSPemDAXWuHXHOVw-1; Tue, 07 Feb 2023 13:51:51 -0500 X-MC-Unique: b6p0KKQSPemDAXWuHXHOVw-1 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7EB15B81AB3; Tue, 7 Feb 2023 18:51:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34265C433EF; Tue, 7 Feb 2023 18:51:47 +0000 (UTC) Date: Tue, 7 Feb 2023 10:51:46 -0800 From: Jakub Kicinski To: Herbert Xu Message-ID: <20230207105146.267fc5e8@kernel.org> In-Reply-To: References: <20230206231008.64c822c1@kernel.org> MIME-Version: 1.0 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mailman-Approved-At: Wed, 08 Feb 2023 07:45:20 +0000 Subject: Re: [dm-devel] [PATCH 0/17] crypto: api - Change completion callback argument to void star X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Howells , dm-devel@redhat.com, keyrings@vger.kernel.org, Alasdair Kergon , Steffen Klassert , Boris Pismenny , John Fastabend , Tyler Hicks , Paolo Abeni , Johan Hedberg , Marcel Holtmann , ecryptfs@vger.kernel.org, Mike Snitzer , Luiz Augusto von Dentz , netdev@vger.kernel.org, Eric Dumazet , Jon Maloy , linux-bluetooth@vger.kernel.org, Jarkko Sakkinen , Linux Crypto Mailing List , Ying Xue , "David S. Miller" Errors-To: dm-devel-bounces@redhat.com Sender: "dm-devel" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 7 Feb 2023 16:03:52 +0800 Herbert Xu wrote: > > Buggy means bug could be hit in real light or buggy == did not use > > the API right? > > Yes this bug is real. If you hit a driver/algorithm that returns > a different request object (of which there are many in the API) then > you will be dereferencing random pointers. Any aes-gcm or chacha-poly implementations which would do that come to mind? I'm asking 'cause we probably want to do stable if we know of a combination which would be broken, or the chances of one existing are high. Otherwise no objections for the patches to go via the crypto tree, there should be no conflicts AFAIK. Feel free to add my ack on the networking changes if needed. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH 0/17] crypto: api - Change completion callback argument to void star Date: Tue, 7 Feb 2023 10:51:46 -0800 Message-ID: <20230207105146.267fc5e8@kernel.org> References: <20230206231008.64c822c1@kernel.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232361AbjBGSvu (ORCPT ); Tue, 7 Feb 2023 13:51:50 -0500 In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" To: Herbert Xu Cc: Linux Crypto Mailing List , Alasdair Kergon , Mike Snitzer , dm-devel@redhat.com, "David S. Miller" , Eric Dumazet , Paolo Abeni , netdev@vger.kernel.org, Tyler Hicks , ecryptfs@vger.kernel.org, Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , linux-bluetooth@vger.kernel.org, Steffen Klassert , Jon Maloy , Ying Xue , Boris Pismenny , John Fastabend , David Howells , Jarkko Sakkinen On Tue, 7 Feb 2023 16:03:52 +0800 Herbert Xu wrote: > > Buggy means bug could be hit in real light or buggy == did not use > > the API right? > > Yes this bug is real. If you hit a driver/algorithm that returns > a different request object (of which there are many in the API) then > you will be dereferencing random pointers. Any aes-gcm or chacha-poly implementations which would do that come to mind? I'm asking 'cause we probably want to do stable if we know of a combination which would be broken, or the chances of one existing are high. Otherwise no objections for the patches to go via the crypto tree, there should be no conflicts AFAIK. Feel free to add my ack on the networking changes if needed.