- 22 Jun, 2017 24 commits
-
-
Mateusz Jurczyk authored
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 <mjurczyk@google.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Gustavo A. R. Silva authored
NULL checks at line 457: if (!link0 || !link1) {, implies that both pointers link0 and link1 might be NULL. Function nfcsim_link_free() dereference pointers link0 and link1. Add NULL checks before calling nfcsim_link_free() to avoid a potential NULL pointer dereference. Addresses-Coverity-ID: 1364857 Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Gustavo A. R. Silva authored
Remove unnecessary NULL check for pointer conn_info. conn_info is set in list_for_each_entry() using container_of(), which is never NULL. Addresses-Coverity-ID: 1362349 Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mateusz Jurczyk authored
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 <mjurczyk@google.com> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mateusz Jurczyk authored
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 <mjurczyk@google.com> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
This reverts commit ab714817. The original commit was designed to handle a bug in the trf7970a NFC controller where an extra byte was returned in Read Multiple Blocks (RMB) command responses. However, it has become less clear whether it is a bug in the trf7970a or in the tag. In addition, it was assumed that the extra byte was always returned but it turns out that is not always the case. The result is that a byte of good data is trimmed off when the extra byte is not present ultimately causing the neard deamon to fail the read. Since the trf7970a driver does not have the context to know when to trim the byte or not, remove the code from the trf7970a driver all together (and move it up to the neard daemon). This has the added benefit of simplifying the kernel driver and putting the extra complexity into userspace. CC: Rob Herring <robh@kernel.org> CC: devicetree@vger.kernel.org Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
Version 1.1 of the NFC Forum's NFC Digital Protocol Technical Specification dated 2014-07-14 specifies that the NFC-DEP Protocol's Target WT(nfcdep,max) value is 14. In version 1.0 it was 8 so change the value in the Linux NFC-DEP Protocol code accordingly. Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
Section 4.8.2 (SEL_RES Response) of NFC Forum's NFC Digital Protocol Technical Specification dated 2010-11-17 clearly states that the size of a SEL_RES Response is one byte. Enforce this restriction in the code. Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Markus Elfring authored
Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Markus Elfring authored
Replace the specification of four data structures by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Colin Ian King authored
The "or" condition (clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) || (clk_freq != TRF7970A_13MHZ_CLOCK_FREQUE) will always be true because clk_freq cannot be equal to two different values at the same time. Use the && operator instead of || to fix this. Detected by CoverityScan, CID#1430468 ("Constant expression result") Fixes: 837eb4d2 ("NFC: trf7970a: add device tree option for 27MHz clock") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Geoff Lansberry <geoff@kuvee.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
There are no longer platform data files for NFC drivers. Remove it from MAINTAINERS data base. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
Since OF and ACPI case almost the same get rid of code duplication by moving gpiod_get() calls directly to ->probe(). Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
In order to make GPIO ACPI library stricter prepare users of gpiod_get_index() to correctly behave when there no mapping is provided by firmware. Here we add explicit mapping between _CRS GpioIo() resources and their names used in the driver. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
Use unified device properties API in meaningful way. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
Since we got rid of platform data, the driver may use GPIO descriptor directly. Looking deeply to the use of the GPIO pin it looks like it should be a GPIO based reset control rather than custom GPIO handling. But this is out of scope of the change. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
I2C and SPI frameworks followed by IRQ framework do set interrupt polarity correctly if it's properly specified in firmware (ACPI or DT). Get rid of the redundant trick when requesting interrupt. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
Legacy platform data must go away. We are on the safe side here since there are no users of it in the kernel. If anyone by any odd reason needs it the GPIO lookup tables and built-in device properties at your service. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
In order to make GPIO ACPI library stricter prepare users of gpiod_get_index() to correctly behave when there no mapping is provided by firmware. Here we add explicit mapping between _CRS GpioIo() resources and their names used in the driver. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
It looks like there are two leftovers, at least one of which can leak the resource (IRQ). Convert both places to use managed variants of the functions. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
There is no platform code that uses i2c module table. Remove it altogether and adjust ->probe() to be ->probe_new(). Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
Since OF and ACPI case almost the same get rid of code duplication by moving gpiod_get() calls directly to ->probe(). Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
In order to make GPIO ACPI library stricter prepare users of gpiod_get_index() to correctly behave when there no mapping is provided by firmware. Here we add explicit mapping between _CRS GpioIo() resources and their names used in the driver. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Andy Shevchenko authored
Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify error path and fix potentially wrong assignment if ->probe() fails. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
- 18 Jun, 2017 16 commits
-
-
Johan Hovold authored
Allow gpio 0 to be used for reset signalling, and instead use negative errnos to disable the reset functionality. Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Johan Hovold authored
Use the USB-interface rather than parent USB-device device, which is what this driver binds to, when registering the nci device. Note that using the right device is important when dealing with device- managed resources as the interface can be unbound independently of the parent device. Also note that private device pointer had already been set by nfcmrvl_nci_register_dev() so the redundant assignment can therefore be removed. Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Johan Hovold authored
Make sure to release the device-node reference when done parsing the node. Fixes: e097dc62 ("NFC: nfcmrvl: add UART driver") Cc: Vincent Cuissard <cuissard@marvell.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Johan Hovold authored
The nci-device was never deregistered in the event that fw-initialisation failed. Fix this by moving the firmware initialisation before device registration since the firmware work queue should be available before registering. Note that this depends on a recent fix that moved device-name initialisation back to to nci_allocate_device() as the firmware-workqueue name is now derived from the nfc-device name. Fixes: 3194c687 ("NFC: nfcmrvl: add firmware download support") Cc: stable <stable@vger.kernel.org> # 4.4 Cc: Vincent Cuissard <cuissard@marvell.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Johan Hovold authored
Use the nfc- rather than phy-device in firmware-management code that needs a valid struct device. This specifically fixes a NULL-pointer dereference in nfcmrvl_fw_dnld_init() during registration when the underlying tty is one end of a Unix98 pty. Note that the driver still uses the phy device for any debugging, which is fine for now. Fixes: 3194c687 ("NFC: nfcmrvl: add firmware download support") Cc: stable <stable@vger.kernel.org> # 4.4 Cc: Vincent Cuissard <cuissard@marvell.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Johan Hovold authored
This specifically fixes resource leaks in the registration error paths. Device-managed resources is a bad fit for this driver as devices can be registered from the n_nci line discipline. Firstly, a tty may not even have a corresponding device (should it be part of a Unix98 pty) something which would lead to a NULL-pointer dereference when registering resources. Secondly, if the tty has a class device, its lifetime exceeds that of the line discipline, which means that resources would leak every time the line discipline is closed (or if registration fails). Currently, the devres interface was only being used to request a reset gpio despite the fact that it was already explicitly freed in nfcmrvl_nci_unregister_dev() (along with the private data), something which also prevented the resource leak at close. Note that the driver treats gpio number 0 as invalid despite it being perfectly valid. This will be addressed in a follow-up patch. Fixes: b2fe288e ("NFC: nfcmrvl: free reset gpio") Fixes: 4a2b947f ("NFC: nfcmrvl: add chip reset management") Cc: stable <stable@vger.kernel.org> # 4.2: b2fe288e Cc: Vincent Cuissard <cuissard@marvell.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Johan Hovold authored
Make sure to check the tty-device pointer before trying to access the parent device to avoid dereferencing a NULL-pointer when the tty is one end of a Unix98 pty. Fixes: e097dc62 ("NFC: nfcmrvl: add UART driver") Cc: stable <stable@vger.kernel.org> # 4.2 Cc: Vincent Cuissard <cuissard@marvell.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Johan Hovold authored
Commit 7eda8b8e ("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: 7eda8b8e ("NFC: Use IDR library to assing NFC devices IDs") Cc: stable <stable@vger.kernel.org> # 3.8 Cc: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
Clean up coding style issues according to scripts/Lindent. Some scripts/Lindent changes were reverted when it appeared to make the code less readable or when it made the line run over 80 characters. Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
The trf7970a driver uses the deprecated integer-based GPIO consumer interface so convert it to use the new descriptor-based GPIO consumer interface. Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
The example DTS code for the trf7970a sets the GPIOs for the EN and EN2 pins to active low when they are really active high so correct the error. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
The 'vin-voltage-override' DT property is used by the trf7970a driver to override the voltage presented to the driver by the regulator subsystem. This is unnecessary as properly specifying the regulator chain via DT properties will accomplish the same thing. Therefore, remove support for 'vin-voltage-override'. Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
The last entry in the trf7970a_of_match[] table must be an empty entry to demarcate the end of the table. Currently, there is a comment indicating this but it is obvious so remove the comment. Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
The quirk indicated by the 'en2-rf-quirk' device tree property is only relevant when there is a GPIO connected to the EN2 pin of the trf7970a. This means we should only check for 'en2-rf-quirk' when EN2 is specified in the 'ti,enable-gpios' property of the device tree. Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
As of commit ce69b95c ("NFC: Make EN2 pin optional in the TRF7970A driver"), only the GPIO for the 'EN' enable pin needs to be specified in the device tree so update the comments that says both 'EN' and 'EN2' must be specified. Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
Mark Greer authored
When the trf7970a part has the bug related to 'en2-rf-quirk', the GPIO connected to the EN2 pin will not be asserted by the driver when powering up so it shouldn't be de-asserted when powering down. Signed-off-by:
Mark Greer <mgreer@animalcreek.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-