Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 14 Jan 2019 10:50:53 +1100
From: Michael Ellerman <>
To: Solar Designer <>,
Cc: Marcel Holtmann <>, Johan Hedberg <>
Subject: Re: Linux kernel: Bluetooth: two remote infoleaks (CVE-2019-3459, CVE-2019-3460)

Solar Designer <> writes:
> Hi,
> Ran Menscher (Bcc'ed on this message) reported two issues (crediting
> "Shlomi Oberman, Yuli Shapiro and Karamba Security Ltd. research team")
> in Linux's Bluetooth stack to linux-distros and security@k.o on
> January 1.  Unfortunately, but unsurprisingly to me, we collectively
> failed to handle these issues well.  We did some things right, but not
> all of those that ideally would have been done before embargo end.  From
> the start, Ran was unwilling to precisely follow the linux-distros list
> policy (set a tentative public disclosure date/time) and to stay on top
> of the issues, instead expecting linux-distros to act more like a CERT
> (coordinate with other parties), which it mostly is not.  I did point
> this out to Ran, and suggested contacting Android, but I think no one
> did that.  (See the third "forwarded message" below on this "not a CERT"
> aspect and what can be done about it.)  The Bluetooth subsystem
> maintainers didn't reply.  Distros appeared uninterested in doing
> anything about the issues under embargo.  There were also numerous
> occasions where I ended up substituting for other distros' roles they
> had volunteered for.  And now I am doing Ran's job of making the
> mandatory posting to oss-security (after a reminder yesterday).
> On the bright side, I appreciate Greg KH's (security@k.o) handling of
> these issues.  Greg took care of notifying the Bluetooth maintainers and
> produced patches suitable for posting to the Linux lists (but still
> needing review and testing), and made such postings as soon as the
> embargo was over.  The thread with patches:
> I also appreciate Yves-Alexis Perez (Debian) assigning the CVE IDs:
>> On Tue, 2019-01-01 at 09:27 +0000, Ran Menscher wrote:
>> CVE-2019-3459
>> CVE-2019-3460
> Also very helpful was Ran's answer that "According to git blame, the
> issues had been introduced in Linux-2.6.12-rc2 (in 2005)"

I'm not sure that's correct. That happens to be the start of the
mainline git history, so all code older than that appears to have been
added by that commit.

Looking at the full history tree, I think I see the bug being introduced
in l2cap_get_conf_opt() here in May 2002 during the 2.5.x series:

Looking at l2cap_parse_conf_req(), the lack of error handling dates back
to the original submission, in v2.4.5.2 in May 2001:

There's instructions for using the fullhistory tree here:


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.