[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YIA09UyI0y6fcb94@kroah.com>
Date: Wed, 21 Apr 2021 16:21:41 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Aditya Pakki <pakki001@....edu>, Kangjie Lu <kjlu@....edu>,
Qiushi Wu <wu000273@....edu>, x86@...nel.org,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Arnd Bergmann <arnd@...db.de>, David Airlie <airlied@...ux.ie>,
Michael Turquette <mturquette@...libre.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Daniel Vetter <daniel@...ll.ch>,
Jean Delvare <jdelvare@...e.com>,
Jiri Kosina <jikos@...nel.org>, Will Deacon <will@...nel.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Johan Hovold <johan@...nel.org>,
Jiri Slaby <jirislaby@...nel.org>,
Pablo Neira Ayuso <pablo@...filter.org>,
Johannes Berg <johannes@...solutions.net>,
Takashi Iwai <tiwai@...e.com>
Subject: Re: [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
Powered by blists - more mailing lists