Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp54641pxy; Wed, 21 Apr 2021 18:18:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz44TjkBp/8UBG5UdJDg4YOOqXEzD0sc28iWP99gjJtTSIwjBY1KoAQBQ0uqMa8+UDqAUH0 X-Received: by 2002:a17:90a:d352:: with SMTP id i18mr15159646pjx.19.1619054328517; Wed, 21 Apr 2021 18:18:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619054328; cv=none; d=google.com; s=arc-20160816; b=GgWxsYLZ+ccEgml0WqHJOsvXiX7iuCQR9E1IvHCHc6Hj3jCAos5FYdywrDymFtFjC6 jmwUuKEzIoEQ1mBv21WFBmddR2+7ek+YLJy9Xbl5/UlO4K9rzm+yP065j8nZI/EGlyWf VLNBkLFvwSfqPWWTiY1b4T4b1WKx+uS50IhQC4PR3tnuA7zvi888Ttc4G6kQqUAlvgnR piZjtt/5zZe7796gTkD3ICNEte204psYELGK6Lmetk5QK/wdrcOya8Su2v4uyipMalLR x4rQqtGswcue4EKGkCrFJE5lSYywd1tXGyXBLR3XuN1+qWTohXgAbs/urJ0UsccvuxfT aaoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=XkmwxQToW0248jxh7a7UntcDTgwlUidpELWqIejJE2k=; b=lgKyTEhUYyQRdnKiphTs76obuKr7y0NSA9RHXPL2GgOQwvPfLf8zUa4mcaBojK7ZkH u+NfoIwcYAwyTevWDPyNnm/phdvFwJX0ZfXSHW0ZMcgMxJLvx5rN38hKJEVMAQZYqb8y DaBSqyn8OilHxY0niSeNIOyoyw6XE6jvYCFWdieUgG7gDewmA5XpukOdVw4a0SgDsvCi +PVXZzr5AgQz9T0qBGKS4S+zN2PvKNg4BdAigSCSCOYpFuvXfBIQkOHlqF9RQVlgt1KH YChegrYiYLEZtcK2fPcm4JDXTcxqFUUij2b4NpAKHR4oT1izriRcelbzyU31Y8OaoGze EJbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 77si1613856pge.14.2021.04.21.18.18.33; Wed, 21 Apr 2021 18:18:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241551AbhDUS6Q convert rfc822-to-8bit (ORCPT + 99 others); Wed, 21 Apr 2021 14:58:16 -0400 Received: from mailout00.webspace-verkauf.com ([37.218.254.21]:60990 "EHLO mailout00.webspace-verkauf.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234093AbhDUS6Q (ORCPT ); Wed, 21 Apr 2021 14:58:16 -0400 X-Greylist: delayed 427 seconds by postgrey-1.27 at vger.kernel.org; Wed, 21 Apr 2021 14:58:15 EDT Received: from c5.webspace-verkauf.de (c5.webspace-verkauf.de [37.218.254.105]) by mailout00.webspace-verkauf.com (Postfix) with ESMTPS id 2C9C14004FD; Wed, 21 Apr 2021 20:50:33 +0200 (CEST) Received: from [192.168.178.20] (pd9fe9a79.dip0.t-ipconnect.de [217.254.154.121]) by c5.webspace-verkauf.de (Postfix) with ESMTPSA id 87A7A1B7B922; Wed, 21 Apr 2021 20:50:32 +0200 (CEST) To: gregkh@linuxfoundation.org Cc: a.shelat@northeastern.edu, anna.schumaker@netapp.com, bfields@fieldses.org, chuck.lever@oracle.com, davem@davemloft.net, dwysocha@redhat.com, kuba@kernel.org, leon@kernel.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, pakki001@umn.edu, sudipm.mukherjee@gmail.com, trondmy@hammerspace.com References: From: Alexander Grund Subject: Re: [PATCH] SUNRPC: Add a check for gss_release_msg Message-ID: <821177ec-dba0-e411-3818-546225511a00@grundis.de> Date: Wed, 21 Apr 2021 20:50:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Content-Language: de-DE Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org > Below is the list that didn't do a simple "revert" that I need to look > at. I was going to have my interns look into this, there's no need to > bother busy maintainers with it unless you really want to, as I can't > tell anyone what to work on :) I'm not involved or affliated with the group or the kernel, but I'd like to make a suggestion: Do not revert umn.edu patches unconditionally. See below: According to the paper: > We submit the three patches using a randomGmail account to the Linux community andseek their feedback So while their behaviour regarding this practice may have been bad, I'd give them the benefit of doubt that they didn't want to actually introduce a bug. I.e. what they wrote: > we immediately notify themaintainers of the introduced UAF and request them to notgo ahead to apply the patch. > At the same time, we point out the correct fixing of the bug and provide our correct patch. > [...] All the UAF-introducing patches stayed only in the emailexchanges, without even becoming a Git commit in Linuxbranches TLDR: - The faulty patches were NOT from umn.edu accounts but from a gmail account - Only the corrected patches should have made it to the branches So while I would at least double-check that the last point is actually true, I believe reverting all umn.edu patches is wrong and actually (re-)introduces vulnerabilities or bugs which have been legitimately fixed (at least in good faith) And especially if the reverts do not apply cleanly on the current HEADs I think you might be wasting a lot of work/time, too. And yes, this aftermath makes it even worse what they did and excluding them from future contributions may make sense. But maybe reverting EVERYTHING is a bit to much here, especially if that doesn't even include the faulty stuff (assuming they are not plain lying in their paper, which I really doubt they would) Alex