Received: by 2002:ac0:f2c4:0:0:0:0:0 with SMTP id f4csp763065imp; Thu, 28 Jul 2022 19:36:11 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tj7r01bCAgXFLypFFAp15CNSFNHRNtAGnYYSmjMP/TwDCdsgPaatBWBZZG0HI1EcPAP3D8 X-Received: by 2002:a17:906:9bd1:b0:72b:302:2b88 with SMTP id de17-20020a1709069bd100b0072b03022b88mr1233340ejc.250.1659062170995; Thu, 28 Jul 2022 19:36:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659062170; cv=none; d=google.com; s=arc-20160816; b=QSH7x1/0pUPMiBQ31oP1dGEP8o+apGSrzl9satTkE13eanddi6kihGJ5yC0lngrARi sxBBL3wHMj7OiQ5qknbR4KSHtxiWgcs4q+RcFXtymC0xLIf/sEdTjRr6gvpE+oM0tJn+ Vm17G45U5I4jTx/ZcotJ70J6AR6OP2SYUCeeZsFYvF97OMsZW+U5spAh0d2ZAzR3PMhr MXFcCNFCO3h1Nxkk/ORrUZYh/zOgcDLfonL5SOnQgBTLmIRPqVoclY68viTjkikJWHUy qUP3mv0CRq4bu5VVOPicyBLyvwqrJHQsC19f/WW0PxHi1ByvXyArQk8zEBiWCz9TdR7q W+ew== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=0W+y4Q0GDbm9edDbDGp7eQq9PMlFwV+jsrmfNIr8vHQ=; b=fZo/atEc7Af5uiFJo4c+naocvJ4KXVn3rQvSVhn0mqG51uOGf6y5wXeyC9n/QokKOR BETEWMvXVjy0n/SiUQ5ZalZ6G/TwphfLEappZPR5m3OiGKTpVf1gbL3uSpGoxb4i4oyr Ml2SLKOPPV6gfYmi3lz5NAbNRU7MnuOOxEUA40YLaT/WS3AFXuLDjoW8dB2m8sm+1Ukj 0Y3T8tXGhNLRR8638nIHf+2o9nyEXjEPl66o4bhdr2Nl2XqRlmhdM5DCIBgOKhKOvtqG lmHbTanRuMeCMhIeHe3fuMZtVqlnLv6/+P8ClZT79Xi76n05+JvmJ+HC+K+x9TUe0TsB et0A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jg21-20020a170907971500b0072b52b30699si2258855ejc.76.2022.07.28.19.35.45; Thu, 28 Jul 2022 19:36:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233785AbiG2CbC (ORCPT + 99 others); Thu, 28 Jul 2022 22:31:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50072 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231522AbiG2Ca7 (ORCPT ); Thu, 28 Jul 2022 22:30:59 -0400 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F10A6A9E4; Thu, 28 Jul 2022 19:30:58 -0700 (PDT) Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1oHFln-005h7C-M5; Fri, 29 Jul 2022 12:30:33 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Fri, 29 Jul 2022 10:30:31 +0800 Date: Fri, 29 Jul 2022 10:30:31 +0800 From: Herbert Xu To: Abhishek Shah Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, steffen.klassert@secunet.com, linux-kernel@vger.kernel.org, Gabriel Ryan , Fan Du Subject: Re: Race 1 in net/xfrm/xfrm_algo.c Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 28, 2022 at 08:00:00PM -0400, Abhishek Shah wrote: > Dear Herbert, > > Thanks for your quick reply and sorry for not being more clear about the > inconsistencies. We identified security implications when algorithms > disappear or reappear during the execution of *compose_sadb_supported*. > > In more detail, > > 1) If after *xfrm_count_pfkey_auth_supported* has finished counting the > available algos, a secondary thread changes the availability of an algo > through *xfrm_probe_algs*, it will return an incorrect number of available > algorithms. If an algo was added during the racing access, the code > allocates a buffer that is smaller than the number of available algorithms > at net/key/af_key.c#L1619 > . > This will result in an out of bounds write when the buffer is later > populated at net/key/af_key.c#L1657 > . OK this is a real bug caused by this commit: commit 283bc9f35bbbcb0e9ab4e6d2427da7f9f710d52d Author: Fan Du Date: Thu Nov 7 17:47:50 2013 +0800 xfrm: Namespacify xfrm state/policy locks It neglected to convert xfrm_probe_algs to namespaces so the previous assumption of exclusive ownership of xfrm_algo_list by the current afkey request is no longer true. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt