linux-stable.git/net/bluetooth, branch linux-3.19.y

Bluetooth: Fix reporting invalid RSSI for LE devices

2015-03-06T22:57:15+00:00

commit 91200e9f3e76af2652952e73ce5d9913f1c987c6 upstream.

Start Discovery was reporting 0 RSSI for invalid RSSI only for
BR/EDR devices. LE devices were reported with RSSI 127.

Signed-off-by: Szymon Janc 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix valid Identity Address check

2015-03-06T22:57:15+00:00

commit e12af489b91d47a806f4e96e4edc20df612482e7 upstream.

According to the Bluetooth core specification valid identity addresses
are either Public Device Addresses or Static Random Addresses. IRKs
received with any other type of address should be discarded since we
cannot assume to know the permanent identity of the peer device.

This patch fixes a missing check for the Identity Address when receiving
the Identity Address Information SMP PDU.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix accepting connections when not using mgmt

2014-12-24T19:02:00+00:00

When connectable mode is enabled (page scan on) through some non-mgmt
method the HCI_CONNECTABLE flag will not be set. For backwards
compatibility with user space versions not using mgmt we should not
require HCI_CONNECTABLE to be set if HCI_MGMT is not set.

Reported-by: Pali Rohár 
Tested-by: Pali Rohár 
Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
Cc: stable@vger.kernel.org # 3.17+

Bluetooth: Fix controller configuration with HCI_QUIRK_INVALID_BDADDR

2014-12-24T18:35:46+00:00

When controllers set the HCI_QUIRK_INVALID_BDADDR flag, it is required
by userspace to program a valid public Bluetooth device address into
the controller before it can be used.

After successful address configuration, the internal state changes and
the controller runs the complete initialization procedure. However one
small difference is that this is no longer the HCI_SETUP stage. The
HCI_SETUP stage is only valid during initial controller setup. In this
case the stack runs the initialization as part of the HCI_CONFIG stage.

The controller version information, default name and supported commands
are only stored during HCI_SETUP. While these information are static,
they are not read initially when HCI_QUIRK_INVALID_BDADDR is set. So
when running in HCI_CONFIG state, these information need to be updated
as well.

This especially impacts Bluetooth 4.1 and later controllers using
extended feature pages and second event mask page.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg 
Cc: stable@vger.kernel.org # 3.17+

Bluetooth: bnep: bnep_add_connection() should verify that it's dealing with l2cap socket

2014-12-19T12:48:27+00:00

same story as cmtp

Signed-off-by: Al Viro 
Signed-off-by: Marcel Holtmann

Bluetooth: cmtp: cmtp_add_connection() should verify that it's dealing with l2cap socket

2014-12-19T12:48:21+00:00

... rather than relying on ciptool(8) never passing it anything else.  Give
it e.g. an AF_UNIX connected socket (from socketpair(2)) and it'll oops,
trying to evaluate &l2cap_pi(sock->sk)->chan->dst...

Signed-off-by: Al Viro 
Signed-off-by: Marcel Holtmann

Bluetooth: hidp_connection_add() unsafe use of l2cap_pi()

2014-12-19T12:40:07+00:00

it's OK after we'd verified the sockets, but not before that.

Signed-off-by: Al Viro 
Signed-off-by: Marcel Holtmann

Bluetooth: 6lowpan: Do not free skb when packet is dropped

2014-12-19T12:39:50+00:00

If we need to drop the message because of some error in the
compression etc, then do not free the skb as that is done
automatically in other part of networking stack.

Signed-off-by: Jukka Rissanen 
Signed-off-by: Marcel Holtmann

Bluetooth: Fix bug with filter in service discovery optimization

2014-12-17T20:03:49+00:00

The optimization for filtering out extended inquiry results, advertising
reports or scan response data based on provided UUID list has a logic
bug. In case no match is found in the advertising data, the scan
response is ignored and not checked against the filter. This will lead
to events being filtered wrongly.

Change the code to actually only drop the events when the scan response
data is not present. If it is present, it needs to be checked against
the provided filter.

The patch is a bit more complex than it needs to be. That is because
it also fixes this compiler warning that some gcc versions produce.

  CC      net/bluetooth/mgmt.o
net/bluetooth/mgmt.c: In function ‘mgmt_device_found’:
net/bluetooth/mgmt.c:7028:7: warning: ‘match’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  bool match;
       ^

It seems that gcc can not clearly figure out the context of the match
variable. So just change the branches for the extended inquiry response
and advertising data around so that it is clear.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next

2014-12-15T18:23:09+00:00