1. 27 Jul, 2017 10 commits
    • 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 30 commits