1. 27 Jul, 2017 16 commits
    • Mateusz Jurczyk's avatar
      nfc: Fix the sockaddr length sanitization in llcp_sock_connect · e66553a5
      Mateusz Jurczyk authored
      commit 608c4adf 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: default avatarMateusz Jurczyk <mjurczyk@google.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e66553a5
    • Mateusz Jurczyk's avatar
      nfc: Ensure presence of required attributes in the activate_target handler · b6a39af4
      Mateusz Jurczyk authored
      commit a0323b97 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: default avatarMateusz Jurczyk <mjurczyk@google.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6a39af4
    • Johan Hovold's avatar
      NFC: nfcmrvl: fix firmware-management initialisation · 36a8a4e9
      Johan Hovold authored
      commit 45dd39b9 upstream.
      
      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: Vincent Cuissard <cuissard@marvell.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36a8a4e9
    • Johan Hovold's avatar
      NFC: nfcmrvl: use nfc-device for firmware download · 7b69ecce
      Johan Hovold authored
      commit e5834ac2 upstream.
      
      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: Vincent Cuissard <cuissard@marvell.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b69ecce
    • Johan Hovold's avatar
      NFC: nfcmrvl: do not use device-managed resources · 6cb06562
      Johan Hovold authored
      commit 0cbe4011 upstream.
      
      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: Vincent Cuissard <cuissard@marvell.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6cb06562
    • Johan Hovold's avatar
      NFC: nfcmrvl_uart: add missing tty-device sanity check · 5d714615
      Johan Hovold authored
      commit 15e0c59f upstream.
      
      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: Vincent Cuissard <cuissard@marvell.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d714615
    • Johan Hovold's avatar
      NFC: fix broken device allocation · 3e540b65
      Johan Hovold authored
      commit 20777bc5 upstream.
      
      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: Samuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e540b65
    • Emmanuel Grumbach's avatar
      iwlwifi: mvm: fix the recovery flow while connecting · bf3d383a
      Emmanuel Grumbach authored
      commit 6b28f978 upstream.
      
      In BSS mode in the disconnection flow, mac80211 removes
      the AP station before the vif is set to unassociated.
      Our firmware wants it the other way around: first set
      the vif as unassociated, and then remove the AP station.
      
      In order to bridge between those two different behaviors,
      iwlmvm doesn't remove the station from the firmware when
      mac80211 removes it, but only after the vif is set to
      unassociated. The implementation is in
      iwl_mvm_bss_info_changed_station:
      
      if (assoc state was modified && mvmvif->ap_sta_id is VALID
          && assoc state is now UNASSC)
      	remove_the_station_from_the_firmware()
      
      During the recovery flow, mac80211 re-adds the AP station
      and then reconfigures the vif. Since the vif is not
      associated, and then, we enter the if above (which was
      intended to be taken in the disconnection flow only) and
      remove the station we just added. This defeats the
      recovery flow.
      
      Fix this by not removing the AP station in this flow if
      we are in recovery flow.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf3d383a
    • Miaoqing Pan's avatar
      ath9k: fix an invalid pointer dereference in ath9k_rng_stop() · a1b6a2c3
      Miaoqing Pan authored
      commit 07246c11 upstream.
      
      The bug was triggered when do suspend/resuming continuously
      on Dell XPS L322X/0PJHXN version 9333 (2013) with kernel
      4.12.0-041200rc4-generic. But can't reproduce on DELL
      E5440 + AR9300 PCIE chips.
      
      The warning is caused by accessing invalid pointer sc->rng_task.
      sc->rng_task is not be cleared after kthread_stop(sc->rng_task)
      be called in ath9k_rng_stop(). Because the kthread is stopped
      before ath9k_rng_kthread() be scheduled.
      
      So set sc->rng_task to null after kthread_stop(sc->rng_task) to
      resolve this issue.
      
      WARNING: CPU: 0 PID: 984 at linux/kernel/kthread.c:71 kthread_stop+0xf1/0x100
      CPU: 0 PID: 984 Comm: NetworkManager Not tainted 4.12.0-041200rc4-generic #201706042031
      Hardware name: Dell Inc.          Dell System XPS L322X/0PJHXN, BIOS A09 05/15/2013
      task: ffff950170fdda00 task.stack: ffffa22c01538000
      RIP: 0010:kthread_stop+0xf1/0x100
      RSP: 0018:ffffa22c0153b5b0 EFLAGS: 00010246
      RAX: ffffffffa6257800 RBX: ffff950171b79560 RCX: 0000000000000000
      RDX: 0000000080000000 RSI: 000000007fffffff RDI: ffff9500ac9a9680
      RBP: ffffa22c0153b5c8 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffa22c0153b648 R11: ffff9501768004b8 R12: ffff9500ac9a9680
      R13: ffff950171b79f70 R14: ffff950171b78780 R15: ffff9501749dc018
      FS:  00007f0d6bfd5540(0000) GS:ffff95017f200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fc190161a08 CR3: 0000000232906000 CR4: 00000000001406f0
      Call Trace:
        ath9k_rng_stop+0x1a/0x20 [ath9k]
        ath9k_stop+0x3b/0x1d0 [ath9k]
        drv_stop+0x33/0xf0 [mac80211]
        ieee80211_stop_device+0x43/0x50 [mac80211]
        ieee80211_do_stop+0x4f2/0x810 [mac80211]
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196043Reported-by: default avatarGiulio Genovese <giulio.genovese@gmail.com>
      Tested-by: default avatarGiulio Genovese <giulio.genovese@gmail.com>
      Signed-off-by: default avatarMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1b6a2c3
    • Miaoqing Pan's avatar
      ath9k: fix tx99 bus error · e9fe79bc
      Miaoqing Pan authored
      commit bde717ab upstream.
      
      The hard coded register 0x9864 and 0x9924 are invalid
      for ar9300 chips.
      Signed-off-by: default avatarMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9fe79bc
    • Miaoqing Pan's avatar
      ath9k: fix tx99 use after free · 33c147af
      Miaoqing Pan authored
      commit cf8ce1ea upstream.
      
      One scenario that could lead to UAF is two threads writing
      simultaneously to the "tx99" debug file. One of them would
      set the "start" value to true and follow to ath9k_tx99_init().
      Inside the function it would set the sc->tx99_state to true
      after allocating sc->tx99skb. Then, the other thread would
      execute write_file_tx99() and call ath9k_tx99_deinit().
      sc->tx99_state would be freed. After that, the first thread
      would continue inside ath9k_tx99_init() and call
      r = ath9k_tx99_send(sc, sc->tx99_skb, &txctl);
      that would make use of the freed sc->tx99_skb memory.
      Signed-off-by: default avatarMiaoqing Pan <miaoqing@codeaurora.org>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33c147af
    • Viresh Kumar's avatar
      thermal: cpu_cooling: Avoid accessing potentially freed structures · b0c64273
      Viresh Kumar authored
      commit 289d72af upstream.
      
      After the lock is dropped, it is possible that the cpufreq_dev gets
      freed before we call get_level() and that can cause kernel to crash.
      
      Drop the lock after we are done using the structure.
      
      Fixes: 02373d7c ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarLukasz Luba <lukasz.luba@arm.com>
      Tested-by: default avatarLukasz Luba <lukasz.luba@arm.com>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0c64273
    • Johan Hovold's avatar
      thermal: max77620: fix device-node reference imbalance · b0bc1293
      Johan Hovold authored
      commit c592fafb upstream.
      
      The thermal child device reuses the parent MFD-device device-tree node
      when registering a thermal zone, but did not take a reference to the
      node.
      
      This leads to a reference imbalance, and potential use-after-free, when
      the node reference is dropped by the platform-bus device destructor
      (once for the child and later again for the parent).
      
      Fix this by dropping any reference already held to a device-tree node
      and getting a reference to the parent's node which will be balanced on
      reprobe or on platform-device release, whichever comes first.
      
      Note that simply clearing the of_node pointer on probe errors and on
      driver unbind would not allow the use of device-managed resources as
      specifically thermal_zone_of_sensor_unregister() claims that a valid
      device-tree node pointer is needed during deregistration (even if it
      currently does not seem to use it).
      
      Fixes: ec4664b3 ("thermal: max77620: Add thermal driver for reporting junction temp")
      Cc: Laxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0bc1293
    • Mauro Carvalho Chehab's avatar
      s5p-jpeg: don't return a random width/height · 7c684630
      Mauro Carvalho Chehab authored
      commit a16e3772 upstream.
      
      Gcc 7.1 complains about:
      
      drivers/media/platform/s5p-jpeg/jpeg-core.c: In function 's5p_jpeg_parse_hdr.isra.9':
      drivers/media/platform/s5p-jpeg/jpeg-core.c:1207:12: warning: 'width' may be used uninitialized in this function [-Wmaybe-uninitialized]
        result->w = width;
        ~~~~~~~~~~^~~~~~~
      drivers/media/platform/s5p-jpeg/jpeg-core.c:1208:12: warning: 'height' may be used uninitialized in this function [-Wmaybe-uninitialized]
        result->h = height;
        ~~~~~~~~~~^~~~~~~~
      
      Indeed the code would allow it to return a random value (although
      it shouldn't happen, in practice). So, explicitly set both to zero,
      just in case.
      Acked-by: default avatarAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c684630
    • Arnd Bergmann's avatar
      ir-core: fix gcc-7 warning on bool arithmetic · 0f2de249
      Arnd Bergmann authored
      commit bd7e31bb upstream.
      
      gcc-7 suggests that an expression using a bitwise not and a bitmask
      on a 'bool' variable is better written using boolean logic:
      
      drivers/media/rc/imon.c: In function 'imon_incoming_scancode':
      drivers/media/rc/imon.c:1725:22: error: '~' on a boolean expression [-Werror=bool-operation]
          ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1;
                            ^
      drivers/media/rc/imon.c:1725:22: note: did you mean to use logical not?
      
      I agree.
      
      Fixes: 21677cfc ("V4L/DVB: ir-core: add imon driver")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f2de249
    • Linus Torvalds's avatar
      disable new gcc-7.1.1 warnings for now · e346433d
      Linus Torvalds authored
      commit bd664f6b upstream.
      
      I made the mistake of upgrading my desktop to the new Fedora 26 that
      comes with gcc-7.1.1.
      
      There's nothing wrong per se that I've noticed, but I now have 1500
      lines of warnings, mostly from the new format-truncation warning
      triggering all over the tree.
      
      We use 'snprintf()' and friends in a lot of places, and often know that
      the numbers are fairly small (ie a controller index or similar), but gcc
      doesn't know that, and sees an 'int', and thinks that it could be some
      huge number.  And then complains when our buffers are not able to fit
      the name for the ten millionth controller.
      
      These warnings aren't necessarily bad per se, and we probably want to
      look through them subsystem by subsystem, but at least during the merge
      window they just mean that I can't even see if somebody is introducing
      any *real* problems when I pull.
      
      So warnings disabled for now.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e346433d
  2. 21 Jul, 2017 24 commits