Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Apr 2015 16:39:05 +0000
From: Shachar Raindel <>
To: Roland Dreier <>
CC: "" <>,
	"<> ("
	<>, ""
Subject: RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical
 memory access

> -----Original Message-----
> From: Roland Dreier []
> Sent: Thursday, April 02, 2015 7:33 PM
> To: Shachar Raindel
> Cc:; <>
> (;
> Subject: Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected
> physical memory access
> On Thu, Apr 2, 2015 at 12:52 AM, Shachar Raindel <>
> wrote:
> > This is a common practice in the security industry, called
> > "responsible disclosure."
> >
> > Following the kernel  security bugs policy [1], we reported it to
> > the kernel security contacts few days before making the issue public.
> > Few days after issue became public, we published a clear report to all
> > of the relevant mailing lists.
> Isn't the point of responsible disclosure to delay disclosure until a
> fix is in place?  What's the point of sending a notification to the
> kernel security team if you're going to disclose publicly before the
> upstream kernel is fixed?

We delayed the disclosure until most major Linux vendors released a fix for
the issue, give or take in synchronization.

The Linux security contact list only guarantee secrecy for 7 days. We
therefore contacted them only close to the date at which fixes were going to
be released, to follow their expectations for period of time between contact
and public disclosure.


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.