“ This issue was initially discovered in 2016 by a RedHat kernel developer and disclosed in a public email thread, but the Linux kernel community did not patch the issue until it was re-reported in 2021.”
People there were thinking about this as a possible fix for a hypothetical crash, not a security issue, and no one was able to prove that there was a crash, nor that the patch fixed it.
No one bothered reviewing it, and the original person who raised the patch didn't advocate further.
None of this seems even close to "insane", this seems like exactly what you expect in most software projects. "Hey, can you explain the bug this patch fixes more?" -> contributor vanishes into the aether -> nothing happens.
Specter/Meltdown was understood to be technically possible since the time pipelined architectures with speculative branching became mainstream in the mid-90s.
Was Spectre as it's understood today ever enunciated though? Not being combative, legitimately looking for papers here because I've read a lot of ones that talk about using side channels to break kernel security [1] and observing that branch predictions are shared (and themselves can be leaked cross context), but never an integrative approach until the Spectre papers dropped. IMO it's one of those things that is so painfully obvious in retrospect but that was a sort of odd blend of works at the time.
> The Linux employees should all be fired for their breach-of-contract with poor Red Hat.
While I appreciate your sarcasm, it is a bit weird that davem dropped that report on the floor altogether for what looks akin to a lack of paperwork.
Not accepting the patch as-is, sure, I get it, process matters. But if the upstream network stack is under your purview one would expect the underlying bug to still be acknowledged, prioritized, and corrected.
This whole thing surprises me since I've interacted with davem via email on multiple occasions. He's always struck me as an asset to the kernel community and caring of upstream issues esp. in the network side.
I'm gonna give him the benefit of the doubt here and presume he assumed the patch's author would follow-up with the necessary acks if it indeed were a genuine bugfix. A lack of follow-up to a maintainer somewhat implies it was a bogus patch and there was nobody willing to corroborate and sign off on it.
Having worked on other large projects with a maintainer model - there is a general lack of ownership. The engineer who is trying to get their patch merged doesn’t feel ownership of the project, and the maintainer rarely feels ownership of any particular CR.
I don’t know if any better model for a project like Linux, but I’d bet good money that neither author nor maintainer felt like they owned the fix for this bug.
Insane.