That's great for sales for these people, but I think the real takeaway here is:
> when the actual merge of the tree was performed, no mention was made of [Linus's] correction to the [original] fix, and with no specific commit mentioning the correction and fixing it alone, everyone else's processes that depended on cherry-picking specific commits ended up grabbing the bad warning-inducing change. As a further failure, instead of looking at Linus' correct fix (observable by checking out the master tree at the time), the approach employed in the LTS kernels seems to have been to naively silence the warning
There are a LOT of process failures in this description of what happened. At the kernel development level, that should be very concerning.
It's good that an external auditor found it (hooray open source), but this was almost definitely an easily preventable mistake with a better process.
> everyone else's processes that depended on cherry-picking specific commits
This alone sounds horrifying.
I don't know anything about kernel development, so I don't want to sit here and judge and offer advice out of ignorance, but I really do feel like there's a better process that would work for them that doesn't involve people "cherry-picking specific commits."