linux-stable.git/net/bluetooth, branch v4.7.3

Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU

2016-08-20T16:10:54+00:00

commit 23bc6ab0a0912146fd674a0becc758c3162baabc upstream.

When we retrieve imtu value from userspace we should use 16 bit pointer
cast instead of 32 as it's defined that way in headers. Fixes setsockopt
calls on big-endian platforms.

Signed-off-by: Amadeusz Sławiński 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: fix power_on vs close race

2016-05-13T14:50:23+00:00

With all the latest fixes applied, I am still able to reproduce this
(and other) warning(s):
WARNING: CPU: 1 PID: 19684 at ../kernel/workqueue.c:4092 destroy_workqueue+0x70a/0x770()
...
Call Trace:
 [] ? dump_stack+0xb3/0x112
 [] ? warn_slowpath_common+0xde/0x140
 [] ? destroy_workqueue+0x70a/0x770
 [] ? warn_slowpath_null+0x2e/0x40
 [] ? destroy_workqueue+0x70a/0x770
 [] ? hci_unregister_dev+0x2a9/0x720 [bluetooth]
 [] ? vhci_release+0x7b/0xf0 [hci_vhci]
 [] ? vhci_flush+0x50/0x50 [hci_vhci]
 [] ? do_exit+0x863/0x2b90

This is due to race present in the hci_unregister_dev path.
hdev->power_on work races with hci_dev_do_close. One tries to open,
the other tries to close, leading to warning like the above. (Another
example is a warning in kobject_get or kobject_put depending on who
wins the race.)

Fix this by switching those two racers to ensure hdev->power_on never
triggers while hci_dev_do_close is in progress.

Signed-off-by: Jiri Slaby 
Signed-off-by: Marcel Holtmann

treewide: replace dev->trans_start update with helper

2016-05-04T18:16:49+00:00

Replace all trans_start updates with netif_trans_update helper.
change was done via spatch:

struct net_device *d;
@@
- d->trans_start = jiffies
+ netif_trans_update(d)

Compile tested only.

Cc: user-mode-linux-devel@lists.sourceforge.net
Cc: linux-xtensa@linux-xtensa.org
Cc: linux1394-devel@lists.sourceforge.net
Cc: linux-rdma@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: MPT-FusionLinux.pdl@broadcom.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-can@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-hams@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: devel@driverdev.osuosl.org
Cc: b.a.t.m.a.n@lists.open-mesh.org
Cc: linux-bluetooth@vger.kernel.org
Signed-off-by: Florian Westphal 
Acked-by: Felipe Balbi 
Acked-by: Mugunthan V N 
Acked-by: Antonio Quartulli 
Signed-off-by: David S. Miller

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

2016-04-26T17:15:56+00:00

Johan Hedberg says:

====================
pull request: bluetooth-next 2016-04-26

Here's another set of Bluetooth & 802.15.4 patches for the 4.7 kernel:

 - Cleanups & refactoring of ieee802154 & 6lowpan code
 - Security related additions to ieee802154 and mrf24j40 driver
 - Memory corruption fix to Bluetooth 6lowpan code
 - Race condition fix in vhci driver
 - Enhancements to the atusb 802.15.4 driver

Please let me know if there are any issues pulling. Thanks.
====================

Signed-off-by: David S. Miller

Bluetooth: 6lowpan: Fix memory corruption of ipv6 destination address

2016-04-25T23:08:25+00:00

The memcpy of ipv6 header destination address to the skb control block
(sbk->cb) in header_create() results in currupted memory when bt_xmit()
is issued. The skb->cb is "released" in the return of header_create()
making room for lower layer to minipulate the skb->cb.

The value retrieved in bt_xmit is not persistent across header creation
and sending, and the lower layer will overwrite portions of skb->cb,
making the copied destination address wrong.

The memory corruption will lead to non-working multicast as the first 4
bytes of the copied destination address is replaced by a value that
resolves into a non-multicast prefix.

This fix removes the dependency on the skb control block between header
creation and send, by moving the destination address memcpy to the send
function path (setup_create, which is called from bt_xmit).

Signed-off-by: Glenn Ruben Bakke 
Acked-by: Jukka Rissanen 
Signed-off-by: Marcel Holtmann 
Cc: stable@vger.kernel.org # 4.5+

sock: tigthen lockdep checks for sock_owned_by_user

2016-04-14T02:37:20+00:00

sock_owned_by_user should not be used without socket lock held. It seems
to be a common practice to check .owned before lock reclassification, so
provide a little help to abstract this check away.

Cc: linux-cifs@vger.kernel.org
Cc: linux-bluetooth@vger.kernel.org
Cc: linux-nfs@vger.kernel.org
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

6lowpan: change naming for lowpan private data

2016-04-13T08:41:09+00:00

This patch changes the naming for interface private data for lowpan
intefaces. The current private data scheme is:

-------------------------------------------------
|    6LoWPAN Generic   |    LinkLayer 6LoWPAN   |
-------------------------------------------------

the current naming schemes are:

- 6LoWPAN Generic:
  - lowpan_priv
- LinkLayer 6LoWPAN:
  - BTLE
    - lowpan_dev
  - 802.15.4:
    - lowpan_dev_info

the new naming scheme with this patch will be:

- 6LoWPAN Generic:
  - lowpan_dev
- LinkLayer 6LoWPAN:
  - BTLE
    - lowpan_btle_dev
  - 802.15.4:
    - lowpan_802154_dev

Signed-off-by: Alexander Aring 
Reviewed-by: Stefan Schmidt
Acked-by: Jukka Rissanen 
Signed-off-by: Marcel Holtmann

Bluetooth: Allow setting BT_SECURITY_FIPS with setsockopt

2016-04-08T17:10:57+00:00

Update the security level check to allow setting BT_SECURITY_FIPS for
an L2CAP socket.

Signed-off-by: Patrik Flykt 
Signed-off-by: Marcel Holtmann

Bluetooth: Ignore unknown advertising packet types

2016-04-08T16:51:44+00:00

In case of buggy controllers send advertising packet types that we
don't know of we should simply ignore them instead of trying to react
to them in some (potentially wrong) way.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: Fix setting NO_BREDR advertising flag

2016-04-08T16:50:40+00:00

If we're dealing with a single-mode controller or BR/EDR is disable
for a dual-mode one, the NO_BREDR flag needs to be unconditionally
present in the advertising data. This patch moves it out from behind
an extra condition to be always set in the create_instance_adv_data()
function if BR/EDR is disabled.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann