[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <E446D456-2566-469A-8252-412E394DDB6B@oracle.com>
Date: Thu, 28 Oct 2021 02:23:10 +0000
From: Roxana Bradescu <roxana.bradescu@...cle.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
CC: Lin Horse <kylin.formalin@...il.com>
Subject: Re: CVE-2021-3760: Linux kernel: Use-After-Free
vulnerability of ndev->rf_conn_info object
> So I think that the distros tasked with reviewing initial notifications
> should insist on the actual date/time being present in there, or add it
> on their own in an immediate follow-up. Those distros currently are
> Oracle and Wind River. I'd appreciate them confirming that they accept
> this clarification.
Acknowledged and agreed.
---
Regards, Roxana
> On Oct 26, 2021, at 4:59 AM, Solar Designer <solar@...nwall.com> wrote:
>
> On Tue, Oct 26, 2021 at 02:37:20PM +0800, Lin Horse wrote:
>> 2021-09-01 Report to security and linux-distro
>> 2021-09-01 CVE-2021-3760 assigned
>> 2021-10-26 patch upstream
>>
>> Sorry for the delay of this report T.T
>
> Ouch. Let's use this opportunity to learn from the mishandling of this
> issue and avoid that for other issues. Many things went wrong here:
>
> 1. The original notification by Lin to linux-distros did include "I'd
> like to ask for 14 days of the embargo", which is OK'ish, but ideally
> such messages should include the proposed public disclosure date/time -
> and that's what the instructions ask for. When it's just "N days", I
> guess people think "that's OK'ish" and move on. When it's a specific
> date/time, it's easier for everyone to notice it approaching - not only
> for people specifically tasked with that. That's just a psychological
> detail that I guess nevertheless statistically affects the outcomes.
>
> So I think that the distros tasked with reviewing initial notifications
> should insist on the actual date/time being present in there, or add it
> on their own in an immediate follow-up. Those distros currently are
> Oracle and Wind River. I'd appreciate them confirming that they accept
> this clarification.
>
> "Promptly review new issue reports for meeting the list's requirements
> and confirm receipt of the report and, when necessary, inform the
> reporter of any issues with their report (e.g., obviously not actionable
> by the distros) and request and/or propose any required yet missing
> information (most notably, a tentative public disclosure date/time) -
> primary: Oracle, backup: Wind River"
>
> 2. While Lin's original message to linux-distros included a "SUGGESTED
> FIX" section (with a patch in it) and "I will do my best to work with
> the developer on fixing this", no further messages on a fix were sent to
> linux-distros. Lin, if you did in fact work with upstream on this, you
> should have kept linux-distros aware of the progress, and especially of
> the fix getting to public Linux kernel mailing lists or public commits,
> as that ends the embargo.
>
> Further, distros failed to handle the corresponding "contributing back"
> tasks. There was no activity by Gentoo lately at all, and while there
> is recent helpful activity by Amazon, they didn't act this time.
>
> "Stay on top of issues to ensure progress is being made, remind others
> when there's no apparent progress, as well as when the public disclosure
> date for an issue is approaching and when it's finally reached (unless
> the reporter beats you to it by making their mandatory posting to
> oss-security first) - primary: Gentoo, backup: Amazon
>
> Monitor relevant public channels (mailing lists, code repositories,
> etc.) and inform the reporter and the list in case an issue is made
> public prematurely (that is, leaks or is independently rediscovered) -
> primary: Amazon, backup: SUSE
>
> Make sure the mandatory oss-security posting is made promptly and is
> sufficiently detailed, and remind the reporter if not - primary: Gentoo,
> backup: Amazon"
>
> I'd like replies by Gentoo and Amazon on this, please. They should
> either state that they'd be handling these tasks from this point on, or
> we should reassign the tasks.
>
> Incidentally, I've already unassigned the statistics task from Gentoo
> and Amazon a while ago, as that one was obviously not handled by them.
> We still need another distro or two to volunteer for this one. As I had
> mentioned, an important desirable side-effect of keeping the statistics
> up-to-date is that this would catch issues that were not reported to
> oss-security in time or at all. For example, if someone were updating
> statistics for September on October 15 (by which point nothing from
> September is supposed to still be embargoed), they'd catch this issue
> 10 days earlier.
>
> 3. The only "contributing back" activity on this issue consisted of 3
> postings to linux-distros: prompt CVE ID assignment by Red Hat, a
> reminder about 14 days having passed by SUSE on September 17 (that is,
> already 3 days past the embargo period end), and another reminder by (a
> different engineer from) SUSE on October 25 (this one worked).
>
> SUSE isn't formally tasked with this - Gentoo and Amazon are - but SUSE
> happened to do it - thanks! SUSE is formally a backup for "Monitor
> relevant public channels ...", which I guess could have worked as well,
> but in this case the embargo period was already over by the time SUSE
> first commented, so that aspect was irrelevant by then.
>
> 4. There's still no (reference to) fix for this issue on oss-security.
> Lin, you write "2021-10-26 patch upstream" - can you please refer to the
> actual upstream commit? Also, can you please let us all know when the
> patch became public (possibly first on a public mailing list)?
>
> This issue itself is not that important, which is part of why it almost
> slipped through the cracks, but it's our reminder and opportunity to fix
> things before anything more important is mishandled.
>
> Alexander
>
> P.S. The Subject of this message as sent by Lin to oss-security
> contained only the CVE ID and no description. I took the liberty to
> edit it, adding the Subject string that was used on linux-distros,
> before approving the message as list moderator.
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
