Comment by thrwwy81faa457
4 days ago
This is the right answer.
Source: 10+y long (past) tenure at RH in a team adjacent to the kernel team.
EDIT: also because companies like RH tend to know, and are happy to know, the details of their customers' deployments. Compare the article:
> Always remember, kernel developers:
> - do not know your use case.
> - do not know what code you use.
> - do not want to know any of this.
https://bugzilla.redhat.com/show_bug.cgi?id=1708775 https://www.openwall.com/lists/oss-security/2020/06/23/2
Even RHEL misses things that don't get announced. This is a big issue for LTS kernels and downstreams, although RHEL does a much better job than most due to the nature of the company/ products.
I don't have tons of examples off hand but Spender and Project Zero have a number of examples like this (not necessarily for RHEL! Just in general where lack of CVE led to downstreams not being patched).
https://googleprojectzero.github.io/0days-in-the-wild/0day-R...
Who is helped by this, for example? https://x.com/grsecurity/status/1486795432202276864
> Always remember, kernel developers: > - do not know your use case. > - do not know what code you use. > - do not want to know any of this.
I just found this part so odd. You don't need to know how users are deploying code to know that a type confusion in an unprivileged system call that leads to full control over the kernel is a vulnerability. If someone has a very strange deployment where that isn't the case, okay, they can choose not to patch.
It's odd for every distro to have to think "is this patch for a vulnerability?" with no insight from upstream on the matter. Thankfully, researchers can go out of their way to get a CVE assigned.