lkml.org 
[lkml]   [2021]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 000/190] Revertion of all of the umn.edu commits
    On Wed, Apr 21, 2021 at 06:56:49AM -0700, Guenter Roeck wrote:
    > On 4/21/21 5:57 AM, Greg Kroah-Hartman wrote:
    > > I have been meaning to do this for a while, but recent events have
    > > finally forced me to do so.
    > >
    > > Commits from @umn.edu addresses have been found to be submitted in "bad
    > > faith" to try to test the kernel community's ability to review "known
    > > malicious" changes. The result of these submissions can be found in a
    > > paper published at the 42nd IEEE Symposium on Security and Privacy
    > > entitled, "Open Source Insecurity: Stealthily Introducing
    > > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
    > > of Minnesota) and Kangjie Lu (University of Minnesota).
    > >
    >
    > Sigh. As if this wouldn't be a problem everywhere.
    >
    > > Because of this, all submissions from this group must be reverted from
    > > the kernel tree and will need to be re-reviewed again to determine if
    > > they actually are a valid fix. Until that work is complete, remove this
    > > change to ensure that no problems are being introduced into the
    > > codebase.
    > >
    > > This patchset has the "easy" reverts, there are 68 remaining ones that
    > > need to be manually reviewed. Some of them are not able to be reverted
    > > as they already have been reverted, or fixed up with follow-on patches
    > > as they were determined to be invalid. Proof that these submissions
    > > were almost universally wrong.
    > >
    > > I will be working with some other kernel developers to determine if any
    > > of these reverts were actually valid changes, were actually valid, and
    > > if so, will resubmit them properly later. For now, it's better to be
    > > safe.
    > >
    > > I'll take this through my tree, so no need for any maintainer to worry
    > > about this, but they should be aware that future submissions from anyone
    > > with a umn.edu address should be by default-rejected unless otherwise
    > > determined to actually be a valid fix (i.e. they provide proof and you
    > > can verify it, but really, why waste your time doing that extra work?)
    > >
    > > thanks,
    > >
    > > greg k-h
    > >
    > [ ... ]
    > > Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"
    >
    > I see
    >
    > 9aa3aa15f4c2 hwmon: (lm80) fix a missing check of bus read in lm80 probe
    > c9c63915519b hwmon: (lm80) fix a missing check of the status of SMBus read
    >
    > The latter indeed introduced a problem which was later fixed with
    >
    > 07bd14ccc304 hwmon: (lm80) Fix missing unlock on error in set_fan_div()
    >
    > I guess that was part of the experiment. I don't see a problem with the
    > patch that is being reverted, but it is not extremely valuable either,
    > so I don't mind the revert. It is not valuable enough to re-apply it later
    > either.
    >
    > FWIW, I didn't see the problem with the second patch even when re-reviewing
    > it, which makes me suspect that they introduced missing-unlock problems on
    > purpose. It is important to keep that in mind when re-reviewing the patches.
    > Also, it may be part of the pattern that they introduced one or more valid
    > patches followed by a malicious one into the same subsystem on purpose.

    Thanks for the review of these, much appreciated.

    greg k-h

    \
     
     \ /
      Last update: 2021-04-21 16:24    [W:2.272 / U:1.652 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site