1. 08 Feb, 2017 2 commits
    • David Ahern's avatar
      lwtunnel: valid encap attr check should return 0 when lwtunnel is disabled · 2bd137de
      David Ahern authored
      An error was reported upgrading to 4.9.8:
          root@Typhoon:~# ip route add default table 210 nexthop dev eth0 via 10.68.64.1
          weight 1 nexthop dev eth0 via 10.68.64.2 weight 1
          RTNETLINK answers: Operation not supported
      
      The problem occurs when CONFIG_LWTUNNEL is not enabled and a multipath
      route is submitted.
      
      The point of lwtunnel_valid_encap_type_attr is catch modules that
      need to be loaded before any references are taken with rntl held. With
      CONFIG_LWTUNNEL disabled, there will be no modules to load so the
      lwtunnel_valid_encap_type_attr stub should just return 0.
      
      Fixes: 9ed59592 ("lwtunnel: fix autoload of lwt modules")
      Reported-by: pupilla@libero.it
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2bd137de
    • Marcus Huewe's avatar
      ipv6: addrconf: fix generation of new temporary addresses · a11a7f71
      Marcus Huewe authored
      Under some circumstances it is possible that no new temporary addresses
      will be generated.
      
      For instance, addrconf_prefix_rcv_add_addr() indirectly calls
      ipv6_create_tempaddr(), which creates a tentative temporary address and
      starts dad. Next, addrconf_prefix_rcv_add_addr() indirectly calls
      addrconf_verify_rtnl(). Now, assume that the previously created temporary
      address has the least preferred lifetime among all existing addresses and
      is still tentative (that is, dad is still running). Hence, the next run of
      addrconf_verify_rtnl() is performed when the preferred lifetime of the
      temporary address ends. If dad succeeds before the next run, the temporary
      address becomes deprecated during the next run, but no new temporary
      address is generated.
      
      In order to fix this, schedule the next addrconf_verify_rtnl() run slightly
      before the temporary address becomes deprecated, if dad succeeded.
      Signed-off-by: default avatarMarcus Huewe <suse-tux@gmx.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a11a7f71
  2. 07 Feb, 2017 17 commits
  3. 06 Feb, 2017 14 commits
    • Linus Torvalds's avatar
      Merge tag 'pm-4.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · f7d6040a
      Linus Torvalds authored
      Pull power management fixes from Rafael Wysocki:
       "These add a quirk to intel_pstate to work around a firmware setting
        that leads to frequency scaling issues (discovered recently) on some
        Intel Kaby Lake processors, fix up the recently added brcmstb-avs
        cpufreq driver and avoid false-positive warnings from the runtime PM
        framework triggered by recent changes in i915.
      
        Specifics:
      
         - Add an intel_pstate driver quirk to work around a firmware setting
           that leads to frequency scaling issues on desktop Intel Kaby Lake
           processors in some configurations if the hardware-managed P-states
           (HWP) feature is in use (Srinivas Pandruvada)
      
         - Fix up the recently added brcmstb-avs cpufreq driver: fix a bug
           related to system suspend and change the sysfs interface to match
           the user space expectations (Markus Mayer)
      
         - Modify the runtime PM framework to avoid false-positive warnings
           from the might_sleep_if() assertions in it (Rafael Wysocki)"
      
      * tag 'pm-4.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        PM / runtime: Avoid false-positive warnings from might_sleep_if()
        cpufreq: intel_pstate: Disable energy efficiency optimization
        cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend
        cpufreq: brcmstb-avs-cpufreq: extend sysfs entry brcm_avs_pmap
      f7d6040a
    • Linus Torvalds's avatar
      Merge tag 'dm-4.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · 50dcb6cd
      Linus Torvalds authored
      Pull device mapper fixes from Mike Snitzer:
      
       - a fix for a race in .request_fn request-based DM request handling vs
         DM device destruction
      
       - an RCU fix for dm-crypt's kernel keyring support that was included in
         4.10-rc1
      
       - a -Wbool-operation warning fix for DM multipath
      
      * tag 'dm-4.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm crypt: replace RCU read-side section with rwsem
        dm rq: cope with DM device destruction while in dm_old_request_fn()
        dm mpath: cleanup -Wbool-operation warning in choose_pgpath()
      50dcb6cd
    • Linus Torvalds's avatar
      Merge tag 'media/v4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · 72df5eba
      Linus Torvalds authored
      Pull media fixes from Mauro Carvalho Chehab:
       "A few documentation fixes at CEC (with got promoted from staging for
        4.10), and one fix on its core."
      
      * tag 'media/v4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
        [media] cec: fix wrong last_la determination
        [media] cec-intro.rst: mention the v4l-utils package and CEC utilities
        [media] cec rst: remove "This API is not yet finalized" notice
      72df5eba
    • Linus Torvalds's avatar
      Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 396bf4cd
      Linus Torvalds authored
      Pull crypto fixes from Herbert Xu:
      
       - use-after-free in algif_aead
      
       - modular aesni regression when pcbc is modular but absent
      
       - bug causing IO page faults in ccp
      
       - double list add in ccp
      
       - NULL pointer dereference in qat (two patches)
      
       - panic in chcr
      
       - NULL pointer dereference in chcr
      
       - out-of-bound access in chcr
      
      * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: chcr - Fix key length for RFC4106
        crypto: algif_aead - Fix kernel panic on list_del
        crypto: aesni - Fix failure when pcbc module is absent
        crypto: ccp - Fix double add when creating new DMA command
        crypto: ccp - Fix DMA operations when IOMMU is enabled
        crypto: chcr - Check device is allocated before use
        crypto: chcr - Fix panic on dma_unmap_sg
        crypto: qat - zero esram only for DH85x devices
        crypto: qat - fix bar discovery for c62x
      396bf4cd
    • Arnd Bergmann's avatar
      hns: avoid stack overflow with CONFIG_KASAN · b3f2d07f
      Arnd Bergmann authored
      The use of ACCESS_ONCE() looks like a micro-optimization to force gcc to use
      an indexed load for the register address, but it has an absolutely detrimental
      effect on builds with gcc-5 and CONFIG_KASAN=y, leading to a very likely
      kernel stack overflow aside from very complex object code:
      
      hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_update_stats':
      hisilicon/hns/hns_dsaf_gmac.c:419:1: error: the frame size of 2912 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_reset_common':
      hisilicon/hns/hns_dsaf_ppe.c:390:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_get_regs':
      hisilicon/hns/hns_dsaf_ppe.c:621:1: error: the frame size of 3632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_common_regs':
      hisilicon/hns/hns_dsaf_rcb.c:970:1: error: the frame size of 2784 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_get_regs':
      hisilicon/hns/hns_dsaf_gmac.c:641:1: error: the frame size of 5728 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_ring_regs':
      hisilicon/hns/hns_dsaf_rcb.c:1021:1: error: the frame size of 2208 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_comm_init':
      hisilicon/hns/hns_dsaf_main.c:1209:1: error: the frame size of 1904 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_xgmac.c: In function 'hns_xgmac_get_regs':
      hisilicon/hns/hns_dsaf_xgmac.c:748:1: error: the frame size of 4704 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_update_stats':
      hisilicon/hns/hns_dsaf_main.c:2420:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_regs':
      hisilicon/hns/hns_dsaf_main.c:2753:1: error: the frame size of 10768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      
      This does not seem to happen any more with gcc-7, but removing the ACCESS_ONCE
      seems safe anyway and it avoids a serious issue for some people. I have verified
      that with gcc-5.3.1, the object code we get is better in the new version
      both with and without CONFIG_KASAN, as we no longer allocate a 1344 byte
      stack frame for hns_dsaf_get_regs() but otherwise have practically identical
      object code.
      
      With gcc-7.0.0, removing ACCESS_ONCE has no effect, the object code is already
      good either way.
      
      This patch is probably not urgent to get into 4.11 as only KASAN=y builds
      with certain compilers are affected, but I still think it makes sense to
      backport into older kernels.
      
      Cc: stable@vger.kernel.org
      Fixes: 511e6bc0 ("net: add Hisilicon Network Subsystem DSAF support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3f2d07f
    • Linus Lüssing's avatar
      ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches · a088d1d7
      Linus Lüssing authored
      When for instance a mobile Linux device roams from one access point to
      another with both APs sharing the same broadcast domain and a
      multicast snooping switch in between:
      
      1)    (c) <~~~> (AP1) <--[SSW]--> (AP2)
      
      2)              (AP1) <--[SSW]--> (AP2) <~~~> (c)
      
      Then currently IPv6 multicast packets will get lost for (c) until an
      MLD Querier sends its next query message. The packet loss occurs
      because upon roaming the Linux host so far stayed silent regarding
      MLD and the snooping switch will therefore be unaware of the
      multicast topology change for a while.
      
      This patch fixes this by always resending MLD reports when an interface
      change happens, for instance from NO-CARRIER to CARRIER state.
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a088d1d7
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2017-02-06' of... · 62f01db9
      David S. Miller authored
      Merge tag 'wireless-drivers-for-davem-2017-02-06' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 4.10
      
      Only one important fix for rtlwifi which fixes a regression introduced
      in 4.9 and which caused problems for many users.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      62f01db9
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2017-02-06' of... · 89389b4d
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2017-02-06' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      A few simple fixes:
       * fix FILS AEAD cipher usage to use the correct AAD vectors
         and to use synchronous algorithms
       * fix using mesh HT operation data from userspace
       * fix adding mesh vendor elements to beacons & plink frames
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89389b4d
    • Eric Dumazet's avatar
      ipv6: tcp: add a missing tcp_v6_restore_cb() · ebf6c9cb
      Eric Dumazet authored
      Dmitry reported use-after-free in ip6_datagram_recv_specific_ctl()
      
      A similar bug was fixed in commit 8ce48623 ("ipv6: tcp: restore
      IP6CB for pktoptions skbs"), but I missed another spot.
      
      tcp_v6_syn_recv_sock() can indeed set np->pktoptions from ireq->pktopts
      
      Fixes: 971f10ec ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebf6c9cb
    • Rafael J. Wysocki's avatar
      Merge branches 'pm-core-fixes' and 'pm-cpufreq-fixes' · cbf304e4
      Rafael J. Wysocki authored
      * pm-core-fixes:
        PM / runtime: Avoid false-positive warnings from might_sleep_if()
      
      * pm-cpufreq-fixes:
        cpufreq: intel_pstate: Disable energy efficiency optimization
        cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend
        cpufreq: brcmstb-avs-cpufreq: extend sysfs entry brcm_avs_pmap
      cbf304e4
    • Masashi Honma's avatar
      nl80211: Fix mesh HT operation check · fd551bac
      Masashi Honma authored
      A previous change to fix checks for NL80211_MESHCONF_HT_OPMODE
      missed setting the flag when replacing FILL_IN_MESH_PARAM_IF_SET
      with checking codes. This results in dropping the received HT
      operation value when called by nl80211_update_mesh_config(). Fix
      this by setting the flag properly.
      
      Fixes: 9757235f ("nl80211: correct checks for NL80211_MESHCONF_HT_OPMODE value")
      Signed-off-by: default avatarMasashi Honma <masashi.honma@gmail.com>
      [rewrite commit message to use Fixes: line]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fd551bac
    • Thorsten Horstmann's avatar
      mac80211: Fix adding of mesh vendor IEs · da7061c8
      Thorsten Horstmann authored
      The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead
      it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The
      return value in mesh_add_vendor_ies must therefore be checked against
      ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with
      WLAN_EID_VENDOR_SPECIFIC will be rejected.
      
      Fixes: 082ebb0c ("mac80211: fix mesh beacon format")
      Signed-off-by: default avatarThorsten Horstmann <thorsten@defutech.de>
      Signed-off-by: default avatarMathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      [sven@narfation.org: Add commit message]
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      da7061c8
    • Jouni Malinen's avatar
      mac80211: Allocate a sync skcipher explicitly for FILS AEAD · 01fba20b
      Jouni Malinen authored
      The skcipher could have been of the async variant which may return from
      skcipher_encrypt() with -EINPROGRESS after having queued the request.
      The FILS AEAD implementation here does not have code for dealing with
      that possibility, so allocate a sync cipher explicitly to avoid
      potential issues with hardware accelerators.
      
      This is based on the patch sent out by Ard.
      
      Fixes: 39404fee ("mac80211: FILS AEAD protection for station mode association frames")
      Reported-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      01fba20b
    • Jouni Malinen's avatar
      mac80211: Fix FILS AEAD protection in Association Request frame · e479ab65
      Jouni Malinen authored
      Incorrect num_elem parameter value (1 vs. 5) was used in the
      aes_siv_encrypt() call. This resulted in only the first one of the five
      AAD vectors to SIV getting included in calculation. This does not
      protect all the contents correctly and would not interoperate with a
      standard compliant implementation.
      
      Fix this by using the correct number. A matching fix is needed in the AP
      side (hostapd) to get FILS authentication working properly.
      
      Fixes: 39404fee ("mac80211: FILS AEAD protection for station mode association frames")
      Reported-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      e479ab65
  4. 05 Feb, 2017 4 commits
  5. 04 Feb, 2017 3 commits