[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE-2021-3760: Linux kernel: Use-After-Free vulnerability of ndev->rf_conn_info o
From:       Roxana Bradescu <roxana.bradescu () oracle ! com>
Date:       2021-10-28 2:23:10
Message-ID: E446D456-2566-469A-8252-412E394DDB6B () oracle ! com
[Download RAW message or body]

> 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@openwall.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.


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE4uuD6pAMWr/SByuBM2FXl4vOf6MFAmF6CY0ACgkQM2FXl4vO
f6OrhhAApr9anJC+RAtjo5NPOPHFoRib5KB/cWvlkFLWeMT0hNynkY1ZvhWUCXd9
76A9wZClNcJm4IT7l/LFqZ24k7AKXq1v/qAny5MU29p8OqP4Y4SLaGXAAngMXLLJ
FaiEgsDMGkH8/pRs9RFCmYAzxiwzWKgSL9Wup7Fg6ITtjzzx3NarL9KMt/+cjeEV
9zhoppwFB3HO2ePjDquuTFRc/D4DTieYfaD9gzOXCvfW1CrS8aGE0uTIXl/NSj74
XurkcSzmaUQIMZD8a+tUU3QiOAko3KprKMwkRHuBpMSw4n+buGe3bNWlsJsfHsle
OKyGRKgXyfovaz/yAM+yqdHYpd70gYLq9irFUNuL5yE/21wkujsQAfUrDksd5TDV
3TTVowfJZvXLI3PitSUDLSZU3CAU6raYh01PeSZnfQ+xBP51ryPdqveK5sjI/Jt2
6zbrFLkwgjhmYwwkpgZIG5kB5IVFGkf1PekvR+Ajqmhh7TS9vvTN97USh165gGfg
RszCqDSkFVWP99TW8k7sSutCjQssCeZPKR3Gm3InmGga26dyU68a5ZBEvePotZvC
TtKQshwtRY1Q0NHTBBic2FpB4ppPeEtWqofsXqGx8isfE9rwhJBaxgTO5o87e7Fi
x76Sbe/jCnVqEz903ntyw+zdQ6JFTN9A3Ome/NqwNWsM+D5YHB8=
=kNbC
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]