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

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

2016-06-08T01:18:52+00:00

commit 55441070ca1cbd47ce1ad2959bbf4b47aed9b83b upstream.

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 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix potential buffer overflow with Add Advertising

2016-04-12T14:33:36+00:00

commit 6a0e78072c2ae7b20b14e0249d8108441ea928d2 upstream.

The Add Advertising command handler does the appropriate checks for
the AD and Scan Response data, however fails to take into account the
general length of the mgmt command itself, which could lead to
potential buffer overflows. This patch adds the necessary check that
the mgmt command length is consistent with the given ad and scan_rsp
lengths.

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

Bluetooth: hci_core: Avoid mixing up req_complete and req_complete_skb

2016-02-20T07:52:28+00:00

In commit 44d271377479 ("Bluetooth: Compress the size of struct
hci_ctrl") we squashed down the size of the structure by using a union
with the assumption that all users would use the flag to determine
whether we had a req_complete or a req_complete_skb.

Unfortunately we had a case in hci_req_cmd_complete() where we weren't
looking at the flag.  This can result in a situation where we might be
storing a hci_req_complete_skb_t in a hci_req_complete_t variable, or
vice versa.

During some testing I found at least one case where the function
hci_req_sync_complete() was called improperly because the kernel thought
that it didn't require an SKB.  Looking through the stack in kgdb I
found that it was called by hci_event_packet() and that
hci_event_packet() had both of its locals "req_complete" and
"req_complete_skb" pointing to the same place: both to
hci_req_sync_complete().

Let's make sure we always check the flag.

For more details on debugging done, see .

Fixes: 44d271377479 ("Bluetooth: Compress the size of struct hci_ctrl")
Signed-off-by: Douglas Anderson 
Acked-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: Fix incorrect removing of IRKs

2016-01-29T10:47:24+00:00

The commit cad20c278085d893ebd616cd20c0747a8e9d53c7 was supposed to
fix handling of devices first using public addresses and then
switching to RPAs after pairing. Unfortunately it missed a couple of
key places in the code.

1. When evaluating which devices should be removed from the existing
white list we also need to consider whether we have an IRK for them or
not, i.e. a call to hci_find_irk_by_addr() is needed.

2. In smp_notify_keys() we should not be requiring the knowledge of
the RPA, but should simply keep the IRK around if the other conditions
require it.

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

Bluetooth: L2CAP: Fix setting chan src info before adding PSM/CID

2016-01-29T10:47:24+00:00

At least the l2cap_add_psm() routine depends on the source address
type being properly set to know what auto-allocation ranges to use, so
the assignment to l2cap_chan needs to happen before this.

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

Bluetooth: L2CAP: Fix auto-allocating LE PSM values

2016-01-29T10:47:24+00:00

The LE dynamic PSM range is different from BR/EDR (0x0080 - 0x00ff)
and doesn't have requirements relating to parity, so separate checks
are needed.

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

Bluetooth: L2CAP: Introduce proper defines for PSM ranges

2016-01-29T10:47:24+00:00

Having proper defines makes the code a bit readable, it also avoids
duplicating hard-coded values since these are also needed when
auto-allocating PSM values (in a subsequent patch).

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

Bluetooth: 6lowpan: Fix handling of uncompressed IPv6 packets

2016-01-23T12:25:53+00:00

This patch fixes incorrect handling of the 6lowpan packets that contain
uncompressed IPv6 header.

RFC4944 specifies a special dispatch for 6lowpan to carry uncompressed
IPv6 header. This dispatch (1 byte long) has to be removed during
reception and skb data pointer has to be moved. To correctly point in
the beginning of the IPv6 header the dispatch byte has to be pulled off
before packet can be processed by netif_rx_in().

Test scenario: IPv6 packets are not correctly interpreted by the network
layer when IPv6 header is not compressed (e.g. ICMPv6 Echo Reply is not
propagated correctly to the ICMPv6 layer because the extra byte will make
the header look corrupted).

Similar approach is done for IEEE 802.15.4.

Signed-off-by: Lukasz Duda 
Signed-off-by: Glenn Ruben Bakke 
Acked-by: Jukka Rissanen 
Signed-off-by: Johan Hedberg 
Cc: stable@vger.kernel.org # 4.4+

Bluetooth: 6lowpan: Fix kernel NULL pointer dereferences

2016-01-23T12:21:47+00:00

The fixes provided in this patch assigns a valid net_device structure to
skb before dispatching it for further processing.

Scenario #1:
============

Bluetooth 6lowpan receives an uncompressed IPv6 header, and dispatches it
to netif. The following error occurs:

Null pointer dereference error #1 crash log:

[  845.854013] BUG: unable to handle kernel NULL pointer dereference at
               0000000000000048
[  845.855785] IP: [] enqueue_to_backlog+0x56/0x240
...
[  845.909459] Call Trace:
[  845.911678]  [] netif_rx_internal+0x44/0xf0

The first modification fixes the NULL pointer dereference error by
assigning dev to the local_skb in order to set a valid net_device before
processing the skb by netif_rx_ni().

Scenario #2:
============

Bluetooth 6lowpan receives an UDP compressed message which needs further
decompression by nhc_udp. The following error occurs:

Null pointer dereference error #2 crash log:

[   63.295149] BUG: unable to handle kernel NULL pointer dereference at
               0000000000000840
[   63.295931] IP: [] udp_uncompress+0x320/0x626
               [nhc_udp]

The second modification fixes the NULL pointer dereference error by
assigning dev to the local_skb in the case of a udp compressed packet.
The 6lowpan udp_uncompress function expects that the net_device is set in
the skb when checking lltype.

Signed-off-by: Glenn Ruben Bakke 
Signed-off-by: Lukasz Duda 
Acked-by: Jukka Rissanen 
Signed-off-by: Johan Hedberg 
Cc: stable@vger.kernel.org # 4.4+

Bluetooth: avoid rebuilding hci_sock all the time

2016-01-06T15:36:44+00:00

Instead, allow using string formatting with send_monitor_note()
and access init_utsname().

Signed-off-by: Johannes Berg 
Signed-off-by: Marcel Holtmann