Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 06 Dec 2017 18:21:04 +0100
From: Adam Maris <>
Subject: Re: Info Leak in the Linux Kernel via Bluetooth

On Wed, 2017-12-06 at 16:23 +0000, Armis Security wrote:
> Hello,
> We are writing to disclose an information leak vulnerability in the
> Bluetooth stack of the Linux Kernel (BlueZ).
> This vulnerability has been disclosed to the Kernel's security team (
>, and a patch for it is in stages of review.
> This patch is also attached here.
> This vulnerability lies in the processing of incoming L2CAP commands
> - ConfigRequest, and ConfigResponse messages.
> This info leak is a result of uninitialized stack variables that may
> be returned to an attacker in their uninitialized state.
> By manipulating the code flows that precede the handling of these
> configuration messages, an attacker can also gain some control over
> which data will be held in the uninitialized stack variables.
> This can allow him to bypass KASLR, and stack canaries protection -
> as both pointers and stack canaries may be leaked in this manner.
> Combining this vulnerability (for example) with the previously
> disclosed RCE vulnerability in L2CAP configuration parsing (CVE-2017-
> 1000251) may allow an attacker to exploit the RCE against kernels
> which were built with the above mitigations.
> These are the specifics of this vulnerability:
> In the function l2cap_parse_conf_rsp and in the function
> l2cap_parse_conf_req the following variable is declared without
> initialization:
> struct l2cap_conf_efs efs;
> In addition, when parsing input configuration parameters in both of
> these functions, the switch case for handling EFS elements may skip
> the memcpy call that will write to the efs variable:
> ...
> 		case L2CAP_CONF_EFS:
> 			if (olen == sizeof(efs))
> 				memcpy(&efs, (void *)val, olen);
> ...
> The olen in the above if is attacker controlled, and regardless of
> that if, in both of these functions the efs variable would eventually
> be added to the outgoing configuration request that is being built:
> l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long)
> &efs);
> So by sending a configuration request, or response, that contains an
> L2CAP_CONF_EFS element, but with an element length that is not
> sizeof(efs) - the memcpy to the uninitialized efs variable can be
> avoided,
> and the uninitialized variable would be returned to the attacker (16
> bytes).

For reference, this issue was assigned CVE-2017-1000410.


Adam Mariš, Red Hat Product Security
1CCD 3446 0529 81E3 86AF  2D4C 4869 76E7 BEF0 6BC2 

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ