[incrudible]

> The vast majority of patches are not malicious.

The vast majority of drunk drivers never kill anyone.

> Sending a malicious patch (one that is known to introduce a vulnerability) is a malicious action.

I disagree that it's malicious in this context, but that's irrelevant really. If the patch gets through, then that proves one of the most critical pieces of software could relatively easily be infiltrated by a malicious actor, which means the review process is broken. That's what we're trying to figure out here, and there's no better way to do it than replicate the same conditions under which such patches would ordinarily be reviewed.

> Especially given that the intent was useless in the first place - everyone knows that patches can introduce vulnerabilities, either maliciously or by accident.

Yes, everyone knows that patches can introduce vulnerabilities if they are not found. We want to know whether they are found! If they are not found, we need to figure out how they slipped by and how to prevent that from happening in the future.

[c22]

Since humanity still hasn't fixed the problem of drunk drivers I guess I'll start driving drunk on the weekends to illustrate the flaws of the system.

[simiones]

> If the patch gets through, then that proves one of the most critical pieces of software could relatively easily be infiltrated by a malicious actor, which means the review process is broken.

That is a complete misunderstanding of the Linux dev process. No one expects the first reviewer of a patch (the person that the researchers were experimenting on) to catch any bug. The dev process has many safeguards - several reviewers, testing, static analysis tools, security research, distribution testing, beta testers, early adopters - that are expected to catch bugs in the kernel at various stages.

Trying to deceive early reviewers into accepting malicious patches for research purposes is both useless research and hurtful to the developers.