[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Oct 2021 13:59:47 +0200
From: Solar Designer <solar@...nwall.com>
To: 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
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.
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.
