linux-stable.git/net/nfc, branch v3.18.78

NFC: Add sockaddr length checks before accessing sa_family in bind handlers

2017-07-27T22:03:24+00:00

commit f6a5885fc4d68e7f25ffb42b9d8d80aebb3bacbb upstream.

Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() handlers of the
AF_NFC socket. Since the syscall doesn't enforce a minimum size of the
corresponding memory region, very short sockaddrs (zero or one byte long)
result in operating on uninitialized memory while referencing .sa_family.

Signed-off-by: Mateusz Jurczyk 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Greg Kroah-Hartman

nfc: Fix the sockaddr length sanitization in llcp_sock_connect

2017-07-27T22:03:24+00:00

commit 608c4adfcabab220142ee335a2a003ccd1c0b25b upstream.

Fix the sockaddr length verification in the connect() handler of NFC/LLCP
sockets, to compare against the size of the actual structure expected on
input (sockaddr_nfc_llcp) instead of its shorter version (sockaddr_nfc).

Both structures are defined in include/uapi/linux/nfc.h. The fields
specific to the _llcp extended struct are as follows:

   276		__u8 dsap; /* Destination SAP, if known */
   277		__u8 ssap; /* Source SAP to be bound to */
   278		char service_name[NFC_LLCP_MAX_SERVICE_NAME]; /* Service name URI */;
   279		size_t service_name_len;

If the caller doesn't provide a sufficiently long sockaddr buffer, these
fields remain uninitialized (and they currently originate from the stack
frame of the top-level sys_connect handler). They are then copied by
llcp_sock_connect() into internal storage (nfc_llcp_sock structure), and
could be subsequently read back through the user-mode getsockname()
function (handled by llcp_sock_getname()). This would result in the
disclosure of up to ~70 uninitialized bytes from the kernel stack to
user-mode clients capable of creating AFC_NFC sockets.

Signed-off-by: Mateusz Jurczyk 
Acked-by: Kees Cook 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Greg Kroah-Hartman

nfc: Ensure presence of required attributes in the activate_target handler

2017-07-27T22:03:24+00:00

commit a0323b979f81ad2deb2c8836eab506534891876a upstream.

Check that the NFC_ATTR_TARGET_INDEX and NFC_ATTR_PROTOCOLS attributes (in
addition to NFC_ATTR_DEVICE_INDEX) are provided by the netlink client
prior to accessing them. This prevents potential unhandled NULL pointer
dereference exceptions which can be triggered by malicious user-mode
programs, if they omit one or both of these attributes.

Signed-off-by: Mateusz Jurczyk 
Acked-by: Kees Cook 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Greg Kroah-Hartman

NFC: fix broken device allocation

2017-07-27T22:03:24+00:00

commit 20777bc57c346b6994f465e0d8261a7fbf213a09 upstream.

Commit 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs")
moved device-id allocation and struct-device initialisation from
nfc_allocate_device() to nfc_register_device().

This broke just about every nfc-device-registration error path, which
continue to call nfc_free_device() that tries to put the device
reference of the now uninitialised (but zeroed) struct device:

kobject: '(null)' (ce316420): is not initialized, yet kobject_put() is being called.

The late struct-device initialisation also meant that various work
queues whose names are derived from the nfc device name were also
misnamed:

  421 root         0 SW<  [(null)_nci_cmd_]
  422 root         0 SW<  [(null)_nci_rx_w]
  423 root         0 SW<  [(null)_nci_tx_w]

Move the id-allocation and struct-device initialisation back to
nfc_allocate_device() and fix up the single call site which did not use
nfc_free_device() in its error path.

Fixes: 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs")
Cc: Samuel Ortiz 
Signed-off-by: Johan Hovold 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Greg Kroah-Hartman

NFC: nci: Add support for proprietary RF Protocols

2014-09-24T00:02:24+00:00

In NFC Forum NCI specification, some RF Protocol values are
reserved for proprietary use (from 0x80 to 0xfe).
Some CLF vendor may need to use one value within this range
for specific technology.
Furthermore, some CLF may not becompliant with NFC Froum NCI
specification 2.0 and therefore will not support RF Protocol
value 0x06 for PROTOCOL_T5T as mention in a draft specification
and in a recent push.

Adding get_rf_protocol handle to the nci_ops structure will
help to set the correct technology to target.

Signed-off-by: Christophe Ricard 
Signed-off-by: Samuel Ortiz

NFC: NCI: Fix NCI RF FRAME interface usage

2014-09-01T12:40:43+00:00

NCI RF FRAME interface is used for all kind of tags
except ISODEP ones. So for all other kind of tags the
status byte has to be removed.

Signed-off-by: Vincent Cuissard 
Signed-off-by: Samuel Ortiz

NFC: NCI: Fix nci_register_device init sequence

2014-09-01T12:40:37+00:00

All contexts have to be initiliazed before calling
nfc_register_device otherwise it is possible to call
nci_dev_up before ending the nci_register_device
function. In such case kernel will crash on non
initialized variables.

Signed-off-by: Vincent Cuissard 
Signed-off-by: Samuel Ortiz

NFC: NCI: Add support of ISO15693

2014-09-01T12:40:31+00:00

Update nci.h to respect latest NCI specification proposal
(stop using proprietary opcodes). Handle ISO15693 parameters
in NCI_RF_ACTIVATED_NTF handler.

Signed-off-by: Vincent Cuissard 
Signed-off-by: Samuel Ortiz

NFC: digital: Add Inititor-side PSL support

2014-08-31T20:15:37+00:00

In order to operate at the fasted bit rate
possible, add initiator-side support for
PSL REQ while in P2P mode.  The PSL REQ
will switch the RF technology to 424F
whenever possible.

Reviewed-by: Thierry Escande 
Tested-by: Thierry Escande 
Signed-off-by: Mark A. Greer 
Signed-off-by: Samuel Ortiz

Merge tag 'master-2014-07-31' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next

2014-08-05T20:18:20+00:00

Conflicts:
	net/6lowpan/iphc.c

Minor conflicts in iphc.c were changes overlapping with some
style cleanups.

John W. Linville says:

====================
Please pull this last(?) batch of wireless change intended for the
3.17 stream...

For the NFC bits, Samuel says:

"This is a rather quiet one, we have:

- A new driver from ST Microelectronics for their NCI ST21NFCB,
  including device tree  support.

- p2p support for the ST21NFCA driver

- A few fixes an enhancements for the NFC digital laye"

For the Atheros bits, Kalle says:

"Michal and Janusz did some important RX aggregation fixes, basically we
were missing RX reordering altogether. The 10.1 firmware doesn't support
Ad-Hoc mode and Michal fixed ath10k so that it doesn't advertise Ad-Hoc
support with that firmware. Also he implemented a workaround for a KVM
issue."

For the Bluetooth bits, Gustavo and Johan say:

"To quote Gustavo from his previous request:

'Some last minute fixes for -next. We have a fix for a use after free in
RFCOMM, another fix to an issue with ADV_DIRECT_IND and one for ADV_IND with
auto-connection handling.  Last, we added support for reading the codec and
MWS setting for controllers that support these features.'

Additionally there are fixes to LE scanning, an update to conform to the 4.1
core specification as well as fixes for tracking the page scan state. All
of these fixes are important for 3.17."

And,

"We've got:

- 6lowpan fixes/cleanups
- A couple crash fixes, one for the Marvell HCI driver and another in LE SMP.
- Fix for an incorrect connected state check
- Fix for the bondable requirement during pairing (an issue which had
  crept in because of using "pairable" when in fact the actual meaning
  was "bondable" (these have different meanings in Bluetooth)"

Along with those are some late-breaking hardware support patches in
brcmfmac and b43 as well as a stray ath9k patch.
====================

Signed-off-by: David S. Miller