linux-kernel - Re: [PATCH] ics932s401: fix broken handling of errors when word reading fails

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 28 Apr 2021 23:20:57 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Darrick J. Wong" <djwong@...nel.org>
Cc:     Matthew Wilcox <willy@...radead.org>, linux-kernel@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>, pakki001@....edu,
        gregkh@...uxfoundation.org, arnd@...db.de
Subject: Re: [PATCH] ics932s401: fix broken handling of errors when word
 reading fails

On Wed, Apr 28, 2021 at 06:03:51PM -0700, Darrick J. Wong wrote:
> I had half expected them all to get reverted immediately, but since 5.12
> went out with this still included, I thought it worth pointing out that
> despite UMN claims that none of their junk patches made it to Linus,
> this (mostly benign) one did.  Granted, maybe 18 Jan 2019 was earlier
> than that, but who knows and who cares? :P

The claim was none of their "hypocrite commits" made it to Linus.
That said nothing about any of their other patches that had been
developed using some of their other research efforts.

Greg isn't planning on sending any of the reverts until the 5.13 merge
window, after doing a lot of reviews to determine which of the 190
commits were actually incorrect, and of those, how many may have
actually introduced security vulnerabilities.  "Good faith hypocrite
commits", if you will.  (Hey, we're all human; I know I've sent my
share of buggy commits where I unintentionally introduced a bug.  :-)

If they can look at the buggy-yet-accepted commits, and map them to
the research efforts in their previous papers, and then do feature
analysis on the bad commits, maybe it will be possible for them to
rework their "hypocrite commit" paper, and perhaps give us some
insights about how to better find buggy commits in our code reviews
--- that is, besides "try harder" and changing the Code of Conduct to
prohibit intentionally introducing bugs (as they had proposed in their
now-withdrawn paper).

Also of interest is of the 68 UMN commits that did not cleanly revert;
it may have been because they were incorrect, but were later fixed
and/or reverted.  In which case, we can probably learn about how long
it takes for problems introduced by "good faith hypocrite commits" to
get fixed naturally, without needing to do an emergency code review of
all UMN patches sent in the past three years or so.

						- Ted