linux-kernel - Re: [PATCH] SUNRPC: Add a check for gss_release

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <821177ec-dba0-e411-3818-546225511a00@grundis.de>
Date:   Wed, 21 Apr 2021 20:50:33 +0200
From:   Alexander Grund <alex@...ndis.de>
To:     gregkh@...uxfoundation.org
Cc:     a.shelat@...theastern.edu, anna.schumaker@...app.com,
        bfields@...ldses.org, chuck.lever@...cle.com, davem@...emloft.net,
        dwysocha@...hat.com, kuba@...nel.org, leon@...nel.org,
        linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org,
        netdev@...r.kernel.org, pakki001@....edu,
        sudipm.mukherjee@...il.com, trondmy@...merspace.com
Subject: Re: [PATCH] SUNRPC: Add a check for gss_release_msg

 > 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