Date: Thu, 18 Mar 2021 20:21:36 +0100 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: Re: CVE-2021-20219 Linux kernel: improper synchronization in flush_to_ldisc() can lead to DoS Hi, FWIW, I agree with what Kurt H Maier wrote. While I wish Red Hat's messages like these were more informative right away, Greg's messages are unfortunately beyond being purely constructive and are in part discouraging. We're lucky that so far his requests for more information actually resulted in just that, and didn't result in Red Hat stopping to post - that is, that others replying had the strength to interpret them constructively despite of their tone suggesting otherwise. OTOH, we have no way to know whether someone was actually discouraged enough not to post on some occasion. Greg, I'd appreciate you not repeating the same things over and over - such as (roughly) "who is this for" and "why did you assign this CVE _now_". Questioning CVE assignment is reasonable and desirable, but only when that is specific (e.g., point out specific reasons why you think an issue might not be CVE worthy) and not generic (questioning every CVE without giving reasons, or asking why bother with CVE for an old issue). As a moderator, I tell you that the kind of messages Red Hat is posting _are_ desirable in here. They could be more detailed, and it's OK to ask for more detail, but it's not OK to discourage their posting. Thank you. On Thu, Mar 18, 2021 at 02:33:21PM -0400, Sasha Levin wrote: > On Thu, Mar 18, 2021 at 10:19:31AM -0700, Kurt H Maier wrote: > >On Thu, Mar 18, 2021 at 01:08:21PM +0100, Greg KH wrote: > >> > >>But none of that takes into account for the backporting of commits into > >>the stable tree, you need a different tool for that, which many of us > >>have our own. If you use that you will see that the above commit really > >>is in lots of fixed kernel trees: > >> > >>$ id_found_in 3d63b7e4ae0dc5e02d28ddd2fa1f945defc68d81 > >>3.16.61 3.18.115 4.4.140 4.9.112 4.14.54 4.17.5 4.18 > > > >It's not really Red Hat's fault that there are six hundred "stable" > >kernel versions, which each change approximately weekly. It's generally > >not worth tracking, and it would not be sane to expect Red Hat to seek > >or announce CVEs for git branches they don't maintain. > > I think that this is an excellent point: RedHat shouldn't be reporting > issues for "Linux Kernel" then. Look at the subject of this mail: > > CVE-2021-20219 Linux kernel: improper synchronization in > flush_to_ldisc() can lead to DoS > > It doesn't say "Red Hat Linux kernel", it just says "Linux kernel", > right? > > Red Hat runs on a forked version of the kernel that has it's own set of > backports, features, and bugs. As you pointed out I think it would make > a lot of sense if they would instead start assigning CVEs for "Red Hat > Linux Kernel". Oh, no. Just no. Red Hat (nor others) shouldn't start to indiscriminately label their CVE assignments for Linux kernel issues (nor for issues in other software they modify and package) like that. I think what we really want is encourage Red Hat (and other distros) to put more effort into figuring out and documenting whether each issue is specific to them or (was) also present in mainline (any version or git commit, but not requiring a review of any branches other than what they possibly took code from). I think they usually already have that information internally. It's just that it didn't propagate into this thread's original message now. It should. Then, for issues that (ever) exist(ed) in upstream kernels, or in any upstream Open Source software for that matter, they should be brought to oss-security. It's very kind of a distro to help us all with that. We should encourage that. For issues that are distro-specific, it's a grey area. First, like you correctly say, they should be labeled accordingly. Then the question of their relevance to oss-security comes up. Among the published content guidelines for oss-security we actually have one asking not to post in here distro-specific advisories aimed at end-users. As I recall, when at some point years ago FreeBSD started sending their advisories in here, I asked them not to. Indeed, we're also not seeing e.g. Red Hat's advisories in here, although they do produce those and send them to proper channels. However, what about distro-specific vulnerability notifications not meant for end-users, but for downstream distros? Using my two examples, both FreeBSD and RHEL do have some downstream or otherwise related distros, who might need to know to merge the fixes. In fact, we have a reverse example of that in this same thread - Virtuozzo had reported the issue to Red Hat presumably due to their reuse of code from RHEL. It can happen both ways, and would also be relevant to third-parties if there are more than two distros reusing distro-specific code like that. It is quite possible that this thread was also noticed and will be acted upon by some other RHEL kernel forks, although chances are those monitor other Red Hat resources and would have learned from there as well. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.