1. 26 Mar, 2014 2 commits
  2. 24 Mar, 2014 4 commits
    • Erik Hugne's avatar
      tipc: fix spinlock recursion bug for failed subscriptions · a5d0e7c0
      Erik Hugne authored
      
      
      If a topology event subscription fails for any reason, such as out
      of memory, max number reached or because we received an invalid
      request the correct behavior is to terminate the subscribers
      connection to the topology server. This is currently broken and
      produces the following oops:
      
      [27.953662] tipc: Subscription rejected, illegal request
      [27.955329] BUG: spinlock recursion on CPU#1, kworker/u4:0/6
      [27.957066]  lock: 0xffff88003c67f408, .magic: dead4ead, .owner: kworker/u4:0/6, .owner_cpu: 1
      [27.958054] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 3.14.0-rc6+ #5
      [27.960230] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [27.960874] Workqueue: tipc_rcv tipc_recv_work [tipc]
      [27.961430]  ffff88003c67f408 ffff88003de27c18 ffffffff815c0207 ffff88003de1c050
      [27.962292]  ffff88003de27c38 ffffffff815beec5 ffff88003c67f408 ffffffff817f0a8a
      [27.963152]  ffff88003de27c58 ffffffff815beeeb ffff88003c67f408 ffffffffa0013520
      [27.964023] Call Trace:
      [27.964292]  [<ffffffff815c0207>] dump_stack+0x45/0x56
      [27.964874]  [<ffffffff815beec5>] spin_dump+0x8c/0x91
      [27.965420]  [<ffffffff815beeeb>] spin_bug+0x21/0x26
      [27.965995]  [<ffffffff81083df6>] do_raw_spin_lock+0x116/0x140
      [27.966631]  [<ffffffff815c6215>] _raw_spin_lock_bh+0x15/0x20
      [27.967256]  [<ffffffffa0008540>] subscr_conn_shutdown_event+0x20/0xa0 [tipc]
      [27.968051]  [<ffffffffa000fde4>] tipc_close_conn+0xa4/0xb0 [tipc]
      [27.968722]  [<ffffffffa00101ba>] tipc_conn_terminate+0x1a/0x30 [tipc]
      [27.969436]  [<ffffffffa00089a2>] subscr_conn_msg_event+0x1f2/0x2f0 [tipc]
      [27.970209]  [<ffffffffa0010000>] tipc_receive_from_sock+0x90/0xf0 [tipc]
      [27.970972]  [<ffffffffa000fa79>] tipc_recv_work+0x29/0x50 [tipc]
      [27.971633]  [<ffffffff8105dbf5>] process_one_work+0x165/0x3e0
      [27.972267]  [<ffffffff8105e869>] worker_thread+0x119/0x3a0
      [27.972896]  [<ffffffff8105e750>] ? manage_workers.isra.25+0x2a0/0x2a0
      [27.973622]  [<ffffffff810648af>] kthread+0xdf/0x100
      [27.974168]  [<ffffffff810647d0>] ? kthread_create_on_node+0x1a0/0x1a0
      [27.974893]  [<ffffffff815ce13c>] ret_from_fork+0x7c/0xb0
      [27.975466]  [<ffffffff810647d0>] ? kthread_create_on_node+0x1a0/0x1a0
      
      The recursion occurs when subscr_terminate tries to grab the
      subscriber lock, which is already taken by subscr_conn_msg_event.
      We fix this by checking if the request to establish a new
      subscription was successful, and if not we initiate termination of
      the subscriber after we have released the subscriber lock.
      Signed-off-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Reviewed-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5d0e7c0
    • Li RongQing's avatar
      netpoll: fix the skb check in pkt_is_ns · c27f0872
      Li RongQing authored
      
      
      Neighbor Solicitation is ipv6 protocol, so we should check
      skb->protocol with ETH_P_IPV6
      Signed-off-by: default avatarLi RongQing <roy.qing.li@gmail.com>
      Cc: WANG Cong <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c27f0872
    • Li RongQing's avatar
      ipv4: remove ip_rt_dump from route.c · 0b8c7f6f
      Li RongQing authored
      
      
      ip_rt_dump do nothing after IPv4 route caches removal, so we can remove it.
      Signed-off-by: default avatarLi RongQing <roy.qing.li@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b8c7f6f
    • Li RongQing's avatar
      ipv4: remove ipv4_ifdown_dst from route.c · 4a4eb21f
      Li RongQing authored
      
      
      ipv4_ifdown_dst does nothing after IPv4 route caches removal,
      so we can remove it.
      Signed-off-by: default avatarLi RongQing <roy.qing.li@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a4eb21f
  3. 22 Mar, 2014 16 commits
  4. 20 Mar, 2014 8 commits
  5. 19 Mar, 2014 10 commits
    • Marcel Holtmann's avatar
      Bluetooth: Enforce strict Secure Connections Only mode security · 40b552aa
      Marcel Holtmann authored
      
      
      In Secure Connections Only mode, it is required that Secure Connections
      is used for pairing and that the link key is encrypted with AES-CCM using
      a P-256 authenticated combination key. If this is not the case, then new
      connection shall be refused or existing connections shall be dropped.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      40b552aa
    • Johan Hedberg's avatar
      Bluetooth: Fix Pair Device response parameters for pairing failure · 4e7b2030
      Johan Hedberg authored
      
      
      It is possible that pairing fails after we've already received remote
      identity information. One example of such a situation is when
      re-encryption using the LTK fails. In this case the hci_conn object has
      already been updated with the identity address but user space does not
      yet know about it (since we didn't notify it of the new IRK yet).
      
      To ensure user space doesn't get a Pair Device command response with an
      unknown address always use the same address in the response as was used
      for the original command.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4e7b2030
    • Johan Hedberg's avatar
      Bluetooth: Fix SMP user passkey notification mgmt event · 01ad34d2
      Johan Hedberg authored
      
      
      When performing SMP pairing with MITM protection one side needs to
      enter the passkey while the other side displays to the user what needs
      to be entered. Nowhere in the SMP specification does it say that the
      displaying side needs to any kind of confirmation of the passkey, even
      though a code comment in smp.c implies this.
      
      This patch removes the misleading comment and converts the code to use
      the passkey notification mgmt event instead of the passkey confirmation
      mgmt event.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      01ad34d2
    • Johan Hedberg's avatar
      Bluetooth: Increase SMP re-encryption delay to 500ms · 5ed884d7
      Johan Hedberg authored
      
      
      In some cases the current 250ms delay is not enough for the remote to
      receive the keys, as can be witnessed by the following log:
      
      > ACL Data RX: Handle 64 flags 0x02 dlen 21               [hci1] 231.414217
            SMP: Signing Information (0x0a) len 16
              Signature key: 555bb66b7ab3abc9d5c287c97fe6eb29
      < ACL Data TX: Handle 64 flags 0x00 dlen 21               [hci1] 231.414414
            SMP: Encryption Information (0x06) len 16
              Long term key: 2a7cdc233c9a4b1f3ed31dd9843fea29
      < ACL Data TX: Handle 64 flags 0x00 dlen 15               [hci1] 231.414466
            SMP: Master Identification (0x07) len 10
              EDIV: 0xeccc
              Rand: 0x322e0ef50bd9308a
      < ACL Data TX: Handle 64 flags 0x00 dlen 21               [hci1] 231.414505
            SMP: Signing Information (0x0a) len 16
              Signature key: bbda1b2076e2325aa66fbcdd5388f745
      > HCI Event: Number of Completed Packets (0x13) plen 5    [hci1] 231.483130
              Num handles: 1
              Handle: 64
              Count: 2
      < HCI Command: LE Start Encryption (0x08|0x0019) plen 28  [hci1] 231.664211
              Handle: 64
              Random number: 0x5052ad2b75fed54b
              Encrypted diversifier: 0xb7c2
              Long term key: a336ede66711b49a84bde9b41426692e
      > HCI Event: Command Status (0x0f) plen 4                 [hci1] 231.666937
            LE Start Encryption (0x08|0x0019) ncmd 1
              Status: Success (0x00)
      > HCI Event: Number of Completed Packets (0x13) plen 5    [hci1] 231.712646
              Num handles: 1
              Handle: 64
              Count: 1
      > HCI Event: Disconnect Complete (0x05) plen 4            [hci1] 232.562587
              Status: Success (0x00)
              Handle: 64
              Reason: Remote User Terminated Connection (0x13)
      
      As can be seen, the last key (Signing Information) is sent at 231.414505
      but the completed packets event for it comes only at 231.712646,
      i.e. roughly 298ms later.
      
      To have a better margin of error this patch increases the delay to
      500ms.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5ed884d7
    • Johan Hedberg's avatar
      Bluetooth: Simplify logic when checking SMP_FLAG_TK_VALID · 18e4aeb9
      Johan Hedberg authored
      
      
      This is a trivial coding style simplification by instead of having an
      extra early return to instead revert the if condition and do the single
      needed queue_work() call there.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      18e4aeb9
    • Zhao, Gang's avatar
      cfg80211: remove macro ASSERT_RDEV_LOCK(rdev) · 73fb08e2
      Zhao, Gang authored
      
      
      Macro ASSERT_RDEV_LOCK(rdev) is equal to ASSERT_RTNL(), so replace it
      with ASSERT_RTNL() and remove it.
      Signed-off-by: default avatarZhao, Gang <gamerh2o@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      73fb08e2
    • Zhao, Gang's avatar
      cfg80211: remove unnecessary check · 4da64622
      Zhao, Gang authored
      
      
      RCU pointer bss->pub.beacon_ies is checked before in previous
      statement:
      
      if (rcu_access_pointer(bss->pub.beacon_ies))
      	continue;
      
      There is no need to check it twice(and in the wrong way :) ).
      Signed-off-by: default avatarZhao, Gang <gamerh2o@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4da64622
    • Emmanuel Grumbach's avatar
      mac80211: set beamforming bit in radiotap · fb378c23
      Emmanuel Grumbach authored
      
      
      Add a bit in rx_status.vht_flags to let the low level driver
      notify mac80211 about a beamformed packet. Propagate this
      to the radiotap header.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fb378c23
    • Emmanuel Grumbach's avatar
      cfg80211/mac80211: ignore signal if the frame was heard on wrong channel · 3afc2167
      Emmanuel Grumbach authored
      
      
      On 2.4Ghz band, the channels overlap since the delta
      between different channels is 5Mhz while the width of the
      receiver is 20Mhz (at least).
      
      This means that we can hear beacons or probe responses from
      adjacent channels. These frames will have a significant
      lower RSSI which will feed all kinds of logic with inaccurate
      data. An obvious example is the roaming algorithm that will
      think our AP is getting weak and will try to move to another
      AP.
      
      In order to avoid this, update the signal only if the frame
      has been heard on the same channel as the one advertised by
      the AP in its DS / HT IEs.
      We refrain from updating the values only if the AP is
      already in the BSS list so that we will still have a valid
      (but inaccurate) value if the AP was heard on an adjacent
      channel only.
      
      To achieve this, stop taking the channel from DS / HT IEs
      in mac80211. The DS / HT IEs is taken into account to
      discard the frame if it was received on a disabled channel.
      This can happen due to the same phenomenon: the frame is
      sent on channel 12, but heard on channel 11 while channel
      12 can be disabled on certain devices. Since this check
      is done in cfg80211, stop even checking this in mac80211.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [remove unused rx_freq variable]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3afc2167
    • Zhao, Gang's avatar
      cfg80211: make __cfg80211_join_ibss() static · 2316d7b0
      Zhao, Gang authored
      
      
      Function __cfg80211_join_ibss() is only used in net/wireless/ibss.c,
      so make it static.
      Signed-off-by: default avatarZhao, Gang <gamerh2o@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      2316d7b0