3 ms·

> the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in

> the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in question. Wait, so none of the maintainers were actually fooled by these hypocrite commits? In 2/3 the maintainers explicitly caught the use-after-free bug on their own, and in the third they had some unrelated feedback. Maybe I mis-read their paper, but they made it sound like if they hadn't told the maintainers "wait, don't merge this, it's bad" they would have introduced vulnerabilities into the kernel. But that isn't what happened at all! Again, maybe I mis-read the paper, but it seems like we can add dishonesty, if not outright fraud, to the list of problems with these researchers.

iudqnolq 5y ago
Possibly? It depends on whether you think every patch they submitted was part of the research. > Thus, one of the first things that happened when this whole affair exploded was the posting by Greg Kroah-Hartman of a 190-part patch series reverting as many patches from UMN as he could find. Actually, it wasn't all of them; he mentioned a list of 68 others requiring manual review because they do not revert easily. > Most of the suspect patches have turned out to be acceptable, if not great, and have been removed from the revert list; if your editor's count is correct, 42 patches are still set to be pulled out of the kernel. > For those 42 patches, the reasoning behind the revert varies from one to the next. In some cases, the patches apply to old and presumably unused drivers and nobody can be bothered to properly review them. In others, the intended change was done poorly and will be reimplemented in a better way. And some of the patches contained serious errors; these definitely needed to be reverted (and should not have been accepted in the first place).

iudqnolq 5y ago

Possibly? It depends on whether you think every patch they submitted was part of the research. > Thus, one of the first things that happened when this whole affair exploded was the posting by Greg Kroah-Hartman of a 190-part patch series reverting as many patches from UMN as he could find. Actually, it wasn't all of them; he mentioned a list of 68 others requiring manual review because they do not revert easily. > Most of the suspect patches have turned out to be acceptable, if not great, and have been removed from the revert list; if your editor's count is correct, 42 patches are still set to be pulled out of the kernel. > For those 42 patches, the reasoning behind the revert varies from one to the next. In some cases, the patches apply to old and presumably unused drivers and nobody can be bothered to properly review them. In others, the intended change was done poorly and will be reimplemented in a better way. And some of the patches contained serious errors; these definitely needed to be reverted (and should not have been accepted in the first place).