1. 01 4月, 2015 1 次提交
    • J
      mac80211: fix RX A-MPDU session reorder timer deletion · 788211d8
      Johannes Berg 提交于
      There's an issue with the way the RX A-MPDU reorder timer is
      deleted that can cause a kernel crash like this:
      
       * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
       * station is destroyed
       * reorder timer fires before ieee80211_free_tid_rx() runs,
         accessing the station, thus potentially crashing due to
         the use-after-free
      
      The station deletion is protected by synchronize_net(), but
      that isn't enough -- ieee80211_free_tid_rx() need not have
      run when that returns (it deletes the timer.) We could use
      rcu_barrier() instead of synchronize_net(), but that's much
      more expensive.
      
      Instead, to fix this, add a field tracking that the session
      is being deleted. In this case, the only re-arming of the
      timer happens with the reorder spinlock held, so make that
      code not rearm it if the session is being deleted and also
      delete the timer after setting that field. This ensures the
      timer cannot fire after ___ieee80211_stop_rx_ba_session()
      returns, which fixes the problem.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      788211d8
  2. 16 3月, 2015 4 次提交
  3. 03 3月, 2015 2 次提交
  4. 27 2月, 2015 1 次提交
    • J
      mac80211: Send EAPOL frames at lowest rate · 9c1c98a3
      Jouni Malinen 提交于
      The current minstrel_ht rate control behavior is somewhat optimistic in
      trying to find optimum TX rate. While this is usually fine for normal
      Data frames, there are cases where a more conservative set of retry
      parameters would be beneficial to make the connection more robust.
      
      EAPOL frames are critical to the authentication and especially the
      EAPOL-Key message 4/4 (the last message in the 4-way handshake) is
      important to get through to the AP. If that message is lost, the only
      recovery mechanism in many cases is to reassociate with the AP and start
      from scratch. This can often be avoided by trying to send the frame with
      more conservative rate and/or with more link layer retries.
      
      In most cases, minstrel_ht is currently using the initial EAPOL-Key
      frames for probing higher rates and this results in only five link layer
      transmission attempts (one at high(ish) MCS and four at MCS0). While
      this works with most APs, it looks like there are some deployed APs that
      may have issues with the EAPOL frames using HT MCS immediately after
      association. Similarly, there may be issues in cases where the signal
      strength or radio environment is not good enough to be able to get
      frames through even at couple of MCS 0 tries.
      
      The best approach for this would likely to be to reduce the TX rate for
      the last rate (3rd rate parameter in the set) to a low basic rate (say,
      6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly
      requires some more effort. For now, we can start with a simple one-liner
      that forces the minimum rate to be used for EAPOL frames similarly how
      the TX rate is selected for the IEEE 802.11 Management frames. This does
      result in a small extra latency added to the cases where the AP would be
      able to receive the higher rate, but taken into account how small number
      of EAPOL frames are used, this is likely to be insignificant. A future
      optimization in the minstrel_ht design can also allow this patch to be
      reverted to get back to the more optimized initial TX rate.
      
      It should also be noted that many drivers that do not use minstrel as
      the rate control algorithm are already doing similar workarounds by
      forcing the lowest TX rate to be used for EAPOL frames.
      
      Cc: stable@vger.kernel.org
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9c1c98a3
  5. 25 2月, 2015 1 次提交
    • J
      mac80211/minstrel: fix !x!=0 confusion · 17dce158
      Jiri Slaby 提交于
      Commit 06d961a8 ("mac80211/minstrel: use the new rate control API")
      inverted the condition 'if (msr->sample_limit != 0)' to
      'if (!msr->sample_limit != 0)'. But it is confusing both to people and
      compilers (gcc5):
      net/mac80211/rc80211_minstrel.c: In function 'minstrel_get_rate':
      net/mac80211/rc80211_minstrel.c:376:26: warning: logical not is only applied to the left hand side of comparison
         if (!msr->sample_limit != 0)
                                ^
      
      Let there be only 'if (!msr->sample_limit)'.
      
      Fixes: 06d961a8 ("mac80211/minstrel: use the new rate control API")
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      17dce158
  6. 24 2月, 2015 5 次提交
  7. 23 2月, 2015 2 次提交
  8. 22 2月, 2015 2 次提交
  9. 21 2月, 2015 6 次提交
  10. 20 2月, 2015 1 次提交
  11. 18 2月, 2015 1 次提交
    • G
      net: dsa: Set valid phy interface type · 19334920
      Guenter Roeck 提交于
      If the phy interface mode is not found in devicetree, or if devicetree
      is not configured, of_get_phy_mode returns -ENODEV. The current code
      sets the phy interface mode to the return value from of_get_phy_mode
      without checking if it is valid.
      
      This invalid phy interface mode is passed as parameter to of_phy_connect
      or to phy_connect_direct. This sets the phy interface mode to the invalid
      value, which in turn causes problems for any code using phydev->interface.
      
      Fixes: b31f65fb ("net: dsa: slave: Fix autoneg for phys on switch MDIO bus")
      Fixes: 0d8bcdd3 ("net: dsa: allow for more complex PHY setups")
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19334920
  12. 17 2月, 2015 3 次提交
    • E
      netfilter: xt_socket: fix a stack corruption bug · 78296c97
      Eric Dumazet 提交于
      As soon as extract_icmp6_fields() returns, its local storage (automatic
      variables) is deallocated and can be overwritten.
      
      Lets add an additional parameter to make sure storage is valid long
      enough.
      
      While we are at it, adds some const qualifiers.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Fixes: b64c9256 ("tproxy: added IPv6 support to the socket match")
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      78296c97
    • F
      netfilter: xt_recent: don't reject rule if new hitcount exceeds table max · cef9ed86
      Florian Westphal 提交于
      given:
      -A INPUT -m recent --update --seconds 30 --hitcount 4
      and
      iptables-save > foo
      
      then
      iptables-restore < foo
      
      will fail with:
      kernel: xt_recent: hitcount (4) is larger than packets to be remembered (4) for table DEFAULT
      
      Even when the check is fixed, the restore won't work if the hitcount is
      increased to e.g. 6, since by the time checkentry runs it will find the
      'old' incarnation of the table.
      
      We can avoid this by increasing the maximum threshold silently; we only
      have to rm all the current entries of the table (these entries would
      not have enough room to handle the increased hitcount).
      
      This even makes (not-very-useful)
      -A INPUT -m recent --update --seconds 30 --hitcount 4
      -A INPUT -m recent --update --seconds 30 --hitcount 42
      work.
      
      Fixes: abc86d0f (netfilter: xt_recent: relax ip_pkt_list_tot restrictions)
      Tracked-down-by: NChris Vine <chris@cvine.freeserve.co.uk>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      cef9ed86
    • P
      netfilter: nft_compat: fix module refcount underflow · 520aa741
      Pablo Neira Ayuso 提交于
      Feb 12 18:20:42 nfdev kernel: ------------[ cut here ]------------
      Feb 12 18:20:42 nfdev kernel: WARNING: CPU: 4 PID: 4359 at kernel/module.c:963 module_put+0x9b/0xba()
      Feb 12 18:20:42 nfdev kernel: CPU: 4 PID: 4359 Comm: ebtables-compat Tainted: G        W      3.19.0-rc6+ #43
      [...]
      Feb 12 18:20:42 nfdev kernel: Call Trace:
      Feb 12 18:20:42 nfdev kernel: [<ffffffff815fd911>] dump_stack+0x4c/0x65
      Feb 12 18:20:42 nfdev kernel: [<ffffffff8103e6f7>] warn_slowpath_common+0x9c/0xb6
      Feb 12 18:20:42 nfdev kernel: [<ffffffff8109919f>] ? module_put+0x9b/0xba
      Feb 12 18:20:42 nfdev kernel: [<ffffffff8103e726>] warn_slowpath_null+0x15/0x17
      Feb 12 18:20:42 nfdev kernel: [<ffffffff8109919f>] module_put+0x9b/0xba
      Feb 12 18:20:42 nfdev kernel: [<ffffffff813ecf7c>] nft_match_destroy+0x45/0x4c
      Feb 12 18:20:42 nfdev kernel: [<ffffffff813e683f>] nf_tables_rule_destroy+0x28/0x70
      Reported-by: NArturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Tested-by: NArturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
      520aa741
  13. 16 2月, 2015 1 次提交
  14. 15 2月, 2015 4 次提交
  15. 14 2月, 2015 1 次提交
  16. 13 2月, 2015 3 次提交
  17. 12 2月, 2015 2 次提交
    • J
      ipv6: fix possible deadlock in ip6_fl_purge / ip6_fl_gc · 4762fb98
      Jan Stancek 提交于
      Use spin_lock_bh in ip6_fl_purge() to prevent following potentially
      deadlock scenario between ip6_fl_purge() and ip6_fl_gc() timer.
      
        =================================
        [ INFO: inconsistent lock state ]
        3.19.0 #1 Not tainted
        ---------------------------------
        inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
        swapper/5/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
         (ip6_fl_lock){+.?...}, at: [<ffffffff8171155d>] ip6_fl_gc+0x2d/0x180
        {SOFTIRQ-ON-W} state was registered at:
          [<ffffffff810ee9a0>] __lock_acquire+0x4a0/0x10b0
          [<ffffffff810efd54>] lock_acquire+0xc4/0x2b0
          [<ffffffff81751d2d>] _raw_spin_lock+0x3d/0x80
          [<ffffffff81711798>] ip6_flowlabel_net_exit+0x28/0x110
          [<ffffffff815f9759>] ops_exit_list.isra.1+0x39/0x60
          [<ffffffff815fa320>] cleanup_net+0x100/0x1e0
          [<ffffffff810ad80a>] process_one_work+0x20a/0x830
          [<ffffffff810adf4b>] worker_thread+0x11b/0x460
          [<ffffffff810b42f4>] kthread+0x104/0x120
          [<ffffffff81752bfc>] ret_from_fork+0x7c/0xb0
        irq event stamp: 84640
        hardirqs last  enabled at (84640): [<ffffffff81752080>] _raw_spin_unlock_irq+0x30/0x50
        hardirqs last disabled at (84639): [<ffffffff81751eff>] _raw_spin_lock_irq+0x1f/0x80
        softirqs last  enabled at (84628): [<ffffffff81091ad1>] _local_bh_enable+0x21/0x50
        softirqs last disabled at (84629): [<ffffffff81093b7d>] irq_exit+0x12d/0x150
      
        other info that might help us debug this:
         Possible unsafe locking scenario:
      
               CPU0
               ----
          lock(ip6_fl_lock);
          <Interrupt>
            lock(ip6_fl_lock);
      
         *** DEADLOCK ***
      Signed-off-by: NJan Stancek <jstancek@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4762fb98
    • A
      mm: gup: use get_user_pages_unlocked · 7e339128
      Andrea Arcangeli 提交于
      This allows those get_user_pages calls to pass FAULT_FLAG_ALLOW_RETRY to
      the page fault in order to release the mmap_sem during the I/O.
      Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
      Reviewed-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Andres Lagar-Cavilla <andreslc@google.com>
      Cc: Peter Feiner <pfeiner@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7e339128