linux-kernel - Re: [PATCH 106/190] Revert "tty: ipwireless: fix missing checks for ioremap"

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: <dd0698e1-9b31-53fc-4dd1-da474cd483bd@kernel.org>
Date:   Thu, 22 Apr 2021 06:57:19 +0200
From:   Jiri Slaby <jirislaby@...nel.org>
To:     dsterba@...e.cz, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, Kangjie Lu <kjlu@....edu>,
        David Sterba <dsterba@...e.com>
Subject: Re: [PATCH 106/190] Revert "tty: ipwireless: fix missing checks for
 ioremap"

On 21. 04. 21, 17:59, David Sterba wrote:
> On Wed, Apr 21, 2021 at 02:59:41PM +0200, Greg Kroah-Hartman wrote:
>> This reverts commit 1bbb1c318cd8a3a39e8c3e2e83d5e90542d6c3e3.
>>
>> 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).
>>
>> 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.
> 
> I've reviewed the patch at the time and now again with fresh eyes, but
> it's IMO a valid fix that would have to be done the same way after
> revert.

ACK -- the same opinion here.

-- 
js
suse labs