Bluetooth: Fix updating Identity Address in L2CAP channels

When we receive a remote identity address during SMP key distribution we
should ensure that any associated L2CAP channel instances get their
address information correspondingly updated (so that e.g. doing
getpeername on associated sockets returns the correct address).

This patch adds a new L2CAP core function l2cap_conn_update_id_addr()
which is used to iterate through all L2CAP channels associated with a
connection and update their address information.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Wait for SMP key distribution completion when pairing

When we initiate pairing through mgmt_pair_device the code has so far
been waiting for a successful HCI Encrypt Change event in order to
respond to the mgmt command. However, putting privacy into the play we
actually want the key distribution to be complete before replying so
that we can include the Identity Address in the mgmt response.

This patch updates the various hci_conn callbacks for LE in mgmt.c to
only respond in the case of failure, and adds a new mgmt_smp_complete
function that the SMP code will call once key distribution has been
completed.

Since the smp_chan_destroy function that's used to indicate completion
and clean up the SMP context can be called from various places,
including outside of smp.c, the easiest way to track failure vs success
is a new flag that we set once key distribution has been successfully
completed.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Don't try to look up private addresses as Identity Address

Identity Addresses are either public or static random. When looking up
addresses based on the Identity Address it doesn't make sense to go
through the IRK list if we're given a private random address. This patch
fixes (or rather improves) the hci_find_irk_by_addr function to bail out
early if given a private random address.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Look up RPA for connection requests with Identity Address

We need to check whether there's a matching IRK and RPA when we're
requested to connect to a remote LE device based on its Identity
Address. This patch updates the hci_connect_le function to do an extra
call to hci_find_irk_by_addr and uses the RPA if it's cached. This is
particularly important once we start exposing the Identity Address to
user space instead of the RPA in events such as Device Connected and
Device Found.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Use Identity Address in Device Found event

Whenever a device uses an RPA we want to have user space identify it by
its Identity Address if we've got an IRK available for it. This patch
updates the Device Found mgmt event to contain the Identity Address if
an IRK is available for the device in question.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Print error when dropping L2CAP data

Silently dropping L2CAP data (i.e. due to remote device not obeying
negotiated MTU) is confusing and makes debugging harder.

Signed-off-by: Szymon Janc <szymon.janc@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
mtip32xx: Reduce the number of unaligned writes to 2

After several experiments, deduced the the optimal number of unaligned
writes to be 2. Changing the value accordingly.

Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Sam Bradshaw <sbradshaw@micron.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Bluetooth: Report identity address when remote device connects

When the remote device has been successfully connected, report the
identity address (public address or static random address).

Currently the address from the HCI_LE_Connection_Complete event is
used. This was no problem so far, but since now known resolvable
random addresses are converted into identities, it is important to
use the identity of the connection and not the address report by
HCI event.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Use connection address for reporting connection failures

When reporting connect failed events to userspace, use the address
of the connection and not the address from the HCI event.

This change is strictly speaking not needed since BR/EDR does not
have the concept of resolvable random addresses. It is more for
making the code consistent.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Fix wrong identity address during connection failures

When the connection attempt fails, the address information are not
provided in the HCI_LE_Connection_Complete event. So use the original
information from the connection to reconstruct the identity address.

This is important when a connection attempt has been made using the
identity address, but the cached resolvable random address has changed
in the meantime. The failure event needs to use the identity address
and not the resolvable random address.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Expose current list of identity resolving keys via debugfs

For debugging purposes expose the current list of identity resolving
keys via debugfs. This file is read-only and limited to root access.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Use same LE min/max connection event length during update

During LE connection establishment the value 0x0000 is used for min/max
connection event length. So use the same value when the peripheral is
requesting an update of the the connection paramters.

For some reason the value 0x0001 got used in the connection update and
0x0000 in the connection creation. Using the same value for both just
makes sense.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
netfilter: remove double colon

This is C not shell script

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
netfilter: xt_ipcomp: Use ntohs to ease sparse warning

0-DAY kernel build testing backend reported:

sparse warnings: (new ones prefixed by >>)

 >> >> net/netfilter/xt_ipcomp.c:63:26: sparse: restricted __be16 degrades to integer
 >> >> net/netfilter/xt_ipcomp.c:63:26: sparse: cast to restricted __be32

Fix this by using ntohs without shifting.

Tested with: make C=1 CF=-D__CHECK_ENDIAN__

Signed-off-by: Fan Du <fan.du@windriver.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
netfilter: nft_ct: labels get support

This also adds NF_CT_LABELS_MAX_SIZE so it can be re-used
as BUILD_BUG_ON in nft_ct.

At this time, nft doesn't yet support writing to the label area;
when this changes the label->words handling needs to be moved
out of xt_connlabel.c into nf_conntrack_labels.c.

Also removes a useless run-time check: words cannot grow beyond
4 (32 bit) or 2 (64bit) since xt_connlabel enforces a maximum of
128 labels.

Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
spi/topcliff-pch: Fix DMA channel

bus_num might be asigned dynamically to e.g. 32766. In this case the
calculated DMA channel based on SPI bus number is bogus. Use SPI channel
number instead for calculation.

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Bluetooth: Avoid using GFP_ATOMIC where not necessary

The various pieces of data cached in the hci_dev structure do not need
to be allocated using GFP_ATOMIC since they are never added from
interrupt context. This patch updates these allocations to use
GFP_KERNEL instead.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Return added key when adding LTKs and IRKs

The SMP code will need to postpone the mgmt event emission for the IRK
and LTKs. To avoid extra lookups at the end of the key distribution
simply return the added value from the add_ltk and add_irk functions.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Move New LTK store hint evaluation into mgmt_new_ltk

It's simpler (one less if-statement) to just evaluate the appropriate
value for store_hint in the mgmt_new_ltk function than to pass a boolean
parameter to the function. Furthermore, this simplifies moving the mgmt
event emission out from hci_add_ltk in subsequent patches.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Track SMP keys in the SMP context

As preparation to do mgmt notification in a single place at the end of
the key distribution, store the keys that need to be notified within the
SMP context.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>