> 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
