1. 06 Jul, 2016 2 commits
  2. 29 Jun, 2016 1 commit
    • Felix Fietkau's avatar
      cfg80211: fix proto in ieee80211_data_to_8023 for frames without LLC header · c041778c
      Felix Fietkau authored
      The PDU length of incoming LLC frames is set to the total skb payload size
      in __ieee80211_data_to_8023() of net/wireless/util.c which incorrectly
      includes the length of the IEEE 802.11 header.
      
      The resulting LLC frame header has a too large PDU length, causing the
      llc_fixup_skb() function of net/llc/llc_input.c to reject the incoming
      skb, effectively breaking STP.
      
      Solve the problem by properly substracting the IEEE 802.11 frame header size
      from the PDU length, allowing the LLC processor to pick up the incoming
      control messages.
      
      Special thanks to Gerry Rozema for tracking down the regression and proposing
      a suitable patch.
      
      Fixes: 2d1c304c ("cfg80211: add function for 802.3 conversion with separate output buffer")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarGerry Rozema <gerryr@rozeware.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      c041778c
  3. 28 Jun, 2016 1 commit
    • Jouni Malinen's avatar
      mac80211: Fix mesh estab_plinks counting in STA removal case · 126e7557
      Jouni Malinen authored
      If a user space program (e.g., wpa_supplicant) deletes a STA entry that
      is currently in NL80211_PLINK_ESTAB state, the number of established
      plinks counter was not decremented and this could result in rejecting
      new plink establishment before really hitting the real maximum plink
      limit. For !user_mpm case, this decrementation is handled by
      mesh_plink_deactive().
      
      Fix this by decrementing estab_plinks on STA deletion
      (mesh_sta_cleanup() gets called from there) so that the counter has a
      correct value and the Beacon frame advertisement in Mesh Configuration
      element shows the proper value for capability to accept additional
      peers.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      126e7557
  4. 09 Jun, 2016 2 commits
    • Prasun Maiti's avatar
      wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel · 3d5fdff4
      Prasun Maiti authored
      iwpriv app uses iw_point structure to send data to Kernel. The iw_point
      structure holds a pointer. For compatibility Kernel converts the pointer
      as required for WEXT IOCTLs (SIOCIWFIRST to SIOCIWLAST). Some drivers
      may use iw_handler_def.private_args to populate iwpriv commands instead
      of iw_handler_def.private. For those case, the IOCTLs from
      SIOCIWFIRSTPRIV to SIOCIWLASTPRIV will follow the path ndo_do_ioctl().
      Accordingly when the filled up iw_point structure comes from 32 bit
      iwpriv to 64 bit Kernel, Kernel will not convert the pointer and sends
      it to driver. So, the driver may get the invalid data.
      
      The pointer conversion for the IOCTLs (SIOCIWFIRSTPRIV to
      SIOCIWLASTPRIV), which follow the path ndo_do_ioctl(), is mandatory.
      This patch adds pointer conversion from 32 bit to 64 bit and vice versa,
      if the ioctl comes from 32 bit iwpriv to 64 bit Kernel.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPrasun Maiti <prasunmaiti87@gmail.com>
      Signed-off-by: default avatarUjjal Roy <royujjal@gmail.com>
      Tested-by: default avatarDibyajyoti Ghosh <dibyajyotig@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3d5fdff4
    • Johannes Berg's avatar
      cfg80211: remove get/set antenna and tx power warnings · 6cbf6236
      Johannes Berg authored
      Since set_tx_power and set_antenna are frequently implemented
      without the matching get_tx_power/get_antenna, we shouldn't
      have added warnings for those. Remove them.
      
      The remaining ones are correct and need to be implemented
      symmetrically for correct operation.
      
      Cc: stable@vger.kernel.org
      Fixes: de3bb771 ("cfg80211: add more warnings for inconsistent ops")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6cbf6236
  5. 31 May, 2016 3 commits
    • Felix Fietkau's avatar
      mac80211: fix fast_tx header alignment · 6fe04128
      Felix Fietkau authored
      The header field is defined as u8[] but also accessed as struct
      ieee80211_hdr. Enforce an alignment of 2 to prevent unnecessary
      unaligned accesses, which can be very harmful for performance on many
      platforms.
      
      Fixes: e495c247 ("mac80211: extend fast-xmit for more ciphers")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6fe04128
    • Bob Copeland's avatar
      mac80211: mesh: flush mesh paths unconditionally · fe7a7c57
      Bob Copeland authored
      Currently, the mesh paths associated with a nexthop station are cleaned
      up in the following code path:
      
          __sta_info_destroy_part1
          synchronize_net()
          __sta_info_destroy_part2
           -> cleanup_single_sta
             -> mesh_sta_cleanup
               -> mesh_plink_deactivate
                 -> mesh_path_flush_by_nexthop
      
      However, there are a couple of problems here:
      
      1) the paths aren't flushed at all if the MPM is running in userspace
         (e.g. when using wpa_supplicant or authsae)
      
      2) there is no synchronize_rcu between removing the path and readers
         accessing the nexthop, which means the following race is possible:
      
      CPU0                            CPU1
      ~~~~                            ~~~~
                                      sta_info_destroy_part1()
                                      synchronize_net()
      rcu_read_lock()
      mesh_nexthop_resolve()
        mpath = mesh_path_lookup()
                                      [...] -> mesh_path_flush_by_nexthop()
        sta = rcu_dereference(
          mpath->next_hop)
                                      kfree(sta)
        access sta <-- CRASH
      
      Fix both of these by unconditionally flushing paths before destroying
      the sta, and by adding a synchronize_net() after path flush to ensure
      no active readers can still dereference the sta.
      
      Fixes this crash:
      
      [  348.529295] BUG: unable to handle kernel paging request at 00020040
      [  348.530014] IP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
      [  348.530014] *pde = 00000000
      [  348.530014] Oops: 0000 [#1] PREEMPT
      [  348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ]
      [  348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G           O 4.6.0-rc5-wt=V1 #1
      [  348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016  11/07/2014
      [  348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000
      [  348.530014] EIP: 0060:[<f929245d>] EFLAGS: 00010246 CPU: 0
      [  348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211]
      [  348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008
      [  348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40
      [  348.530014]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
      [  348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690
      [  348.530014] Stack:
      [  348.530014]  00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0
      [  348.530014]  f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320
      [  348.530014]  f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1
      [  348.530014] Call Trace:
      [  348.530014]  [<f9291d80>] mesh_nexthop_lookup+0xbb/0xc8 [mac80211]
      [  348.530014]  [<f9291dc1>] mesh_nexthop_resolve+0x34/0xd8 [mac80211]
      [  348.530014]  [<f9277f6f>] ieee80211_xmit+0x92/0xc1 [mac80211]
      [  348.530014]  [<f9278dd1>] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211]
      [  348.530014]  [<c04df012>] ? sch_direct_xmit+0xd7/0x1b3
      [  348.530014]  [<c022a8c6>] ? __local_bh_enable_ip+0x5d/0x7b
      [  348.530014]  [<f956870c>] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4]
      [  348.530014]  [<f957e036>] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat]
      [  348.530014]  [<c04c6f45>] ? netif_skb_features+0x14d/0x30a
      [  348.530014]  [<f9278e10>] ieee80211_subif_start_xmit+0xa/0xe [mac80211]
      [  348.530014]  [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
      [  348.530014]  [<c04c7261>] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
      [  348.530014]  [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
      [  348.530014]  [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
      [  348.530014]  [<c04c7cfb>] dev_queue_xmit+0xa/0xc
      [  348.530014]  [<f91bfc7a>] batadv_send_skb_packet+0xd6/0xec [batman_adv]
      [  348.530014]  [<f91bfdc4>] batadv_send_unicast_skb+0x15/0x4a [batman_adv]
      [  348.530014]  [<f91b5938>] batadv_dat_send_data+0x27e/0x310 [batman_adv]
      [  348.530014]  [<f91c30b5>] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv]
      [  348.530014]  [<f91b63f3>] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv]
      [  348.530014]  [<f91c0cd9>] batadv_interface_tx+0x206/0x385 [batman_adv]
      [  348.530014]  [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267
      [  348.530014]  [<c04c7261>] ?  validate_xmit_skb.isra.120.part.121+0x10/0x253
      [  348.530014]  [<c04defc6>] sch_direct_xmit+0x8b/0x1b3
      [  348.530014]  [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513
      [  348.530014]  [<f80cbd2a>] ? igb_xmit_frame+0x57/0x72 [igb]
      [  348.530014]  [<c04c7cfb>] dev_queue_xmit+0xa/0xc
      [  348.530014]  [<f843a326>] br_dev_queue_push_xmit+0xeb/0xfb [bridge]
      [  348.530014]  [<f843a35f>] br_forward_finish+0x29/0x74 [bridge]
      [  348.530014]  [<f843a23b>] ? deliver_clone+0x3b/0x3b [bridge]
      [  348.530014]  [<f843a714>] __br_forward+0x89/0xe7 [bridge]
      [  348.530014]  [<f843a336>] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge]
      [  348.530014]  [<f843a234>] deliver_clone+0x34/0x3b [bridge]
      [  348.530014]  [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
      [  348.530014]  [<f843a66d>] br_flood+0x77/0x95 [bridge]
      [  348.530014]  [<f843a809>] br_flood_forward+0x13/0x1a [bridge]
      [  348.530014]  [<f843a68b>] ? br_flood+0x95/0x95 [bridge]
      [  348.530014]  [<f843b877>] br_handle_frame_finish+0x392/0x3db [bridge]
      [  348.530014]  [<c04e9b2b>] ? nf_iterate+0x2b/0x6b
      [  348.530014]  [<f843baa6>] br_handle_frame+0x1e6/0x240 [bridge]
      [  348.530014]  [<f843b4e5>] ? br_handle_local_finish+0x6a/0x6a [bridge]
      [  348.530014]  [<c04c4ba0>] __netif_receive_skb_core+0x43a/0x66b
      [  348.530014]  [<f843b8c0>] ? br_handle_frame_finish+0x3db/0x3db [bridge]
      [  348.530014]  [<c023cea4>] ? resched_curr+0x19/0x37
      [  348.530014]  [<c0240707>] ? check_preempt_wakeup+0xbf/0xfe
      [  348.530014]  [<c0255dec>] ? ktime_get_with_offset+0x5c/0xfc
      [  348.530014]  [<c04c4fc1>] __netif_receive_skb+0x47/0x55
      [  348.530014]  [<c04c57ba>] netif_receive_skb_internal+0x40/0x5a
      [  348.530014]  [<c04c61ef>] napi_gro_receive+0x3a/0x94
      [  348.530014]  [<f80ce8d5>] igb_poll+0x6fd/0x9ad [igb]
      [  348.530014]  [<c0242bd8>] ? swake_up_locked+0x14/0x26
      [  348.530014]  [<c04c5d29>] net_rx_action+0xde/0x250
      [  348.530014]  [<c022a743>] __do_softirq+0x8a/0x163
      [  348.530014]  [<c022a6b9>] ? __hrtimer_tasklet_trampoline+0x19/0x19
      [  348.530014]  [<c021100f>] do_softirq_own_stack+0x26/0x2c
      [  348.530014]  <IRQ>
      [  348.530014]  [<c022a957>] irq_exit+0x31/0x6f
      [  348.530014]  [<c0210eb2>] do_IRQ+0x8d/0xa0
      [  348.530014]  [<c058152c>] common_interrupt+0x2c/0x40
      [  348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005
      [  348.530014] EIP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40
      [  348.530014] CR2: 0000000000020040
      [  348.530014] ---[ end trace 48556ac26779732e ]---
      [  348.530014] Kernel panic - not syncing: Fatal exception in interrupt
      [  348.530014] Kernel Offset: disabled
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarFred Veldini <fred.veldini@gmail.com>
      Tested-by: default avatarFred Veldini <fred.veldini@gmail.com>
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fe7a7c57
    • Martin Willi's avatar
      mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL · 62397da5
      Martin Willi authored
      A wmediumd that does not send this attribute causes a NULL pointer
      dereference, as the attribute is accessed even if it does not exist.
      
      The attribute was required but never checked ever since userspace frame
      forwarding has been introduced. The issue gets more problematic once we
      allow wmediumd registration from user namespaces.
      
      Cc: stable@vger.kernel.org
      Fixes: 7882513b ("mac80211_hwsim driver support userspace frame tx/rx")
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      62397da5
  6. 30 May, 2016 9 commits
  7. 26 May, 2016 17 commits
  8. 25 May, 2016 5 commits
    • Feng Tang's avatar
      net: alx: use custom skb allocator · 26c5f03b
      Feng Tang authored
      This patch follows Eric Dumazet's commit 7b701764 for Atheros
      atl1c driver to fix one exactly same bug in alx driver, that the
      network link will be lost in 1-5 minutes after the device is up.
      
      My laptop Lenovo Y580 with Atheros AR8161 ethernet device hit the
      same problem with kernel 4.4, and it will be cured by Jarod Wilson's
      commit c406700c for alx driver which get merged in 4.5. But there
      are still some alx devices can't function well even with Jarod's
      patch, while this patch could make them work fine. More details on
      	https://bugzilla.kernel.org/show_bug.cgi?id=70761
      
      The debug shows the issue is very likely to be related with the RX
      DMA address, specifically 0x...f80, if RX buffer get 0x...f80 several
      times, their will be RX overflow error and device will stop working.
      
      For kernel 4.5.0 with Jarod's patch which works fine with my
      AR8161/Lennov Y580, if I made some change to the
      	__netdev_alloc_skb
      		--> __alloc_page_frag()
      to make the allocated buffer can get an address with 0x...f80,
      then the same error happens. If I make it to 0x...f40 or 0x....fc0,
      everything will be still fine. So I tend to believe that the
      0x..f80 address cause the silicon to behave abnormally.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70761
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Jarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarFeng Tang <feng.tang@intel.com>
      Tested-by: default avatarOle Lukoie <olelukoie@mail.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26c5f03b
    • Ivan Vecera's avatar
      team: don't call netdev_change_features under team->lock · f6988cb6
      Ivan Vecera authored
      The team_device_event() notifier calls team_compute_features() to fix
      vlan_features under team->lock to protect team->port_list. The problem is
      that subsequent __team_compute_features() calls netdev_change_features()
      to propagate vlan_features to upper vlan devices while team->lock is still
      taken. This can lead to deadlock when NETIF_F_LRO is modified on lower
      devices or team device itself.
      
      Example:
      The team0 as active backup with eth0 and eth1 NICs. Both eth0 & eth1 are
      LRO capable and LRO is enabled. Thus LRO is also enabled on team0.
      
      The command 'ethtool -K team0 lro off' now hangs due to this deadlock:
      
      dev_ethtool()
      -> ethtool_set_features()
       -> __netdev_update_features(team)
        -> netdev_sync_lower_features()
         -> netdev_update_features(lower_1)
          -> __netdev_update_features(lower_1)
          -> netdev_features_change(lower_1)
           -> call_netdevice_notifiers(...)
            -> team_device_event(lower_1)
             -> team_compute_features(team) [TAKES team->lock]
              -> netdev_change_features(team)
               -> __netdev_update_features(team)
                -> netdev_sync_lower_features()
                 -> netdev_update_features(lower_2)
                  -> __netdev_update_features(lower_2)
                  -> netdev_features_change(lower_2)
                   -> call_netdevice_notifiers(...)
                    -> team_device_event(lower_2)
                     -> team_compute_features(team) [DEADLOCK]
      
      The bug is present in team from the beginning but it appeared after the commit
      fd867d51 (net/core: generic support for disabling netdev features down stack)
      that adds synchronization of features with lower devices.
      
      Fixes: fd867d51 (net/core: generic support for disabling netdev features down stack)
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6988cb6
    • David S. Miller's avatar
      Merge branch 'dsa-doc-fixes' · f58fb330
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      Documentation: dsa: misc fixes
      
      Here are some miscelaneous documentation fixes for DSA, I targeted "net"
      because these are not functional code changes, but still documentation fixes
      per-se.
      
      Changes in v2:
      
      - reword what the port_vlan_filtering is about based on feedback from Vivien and Ido
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f58fb330
    • Florian Fainelli's avatar
      Documentation: networking: dsa: Describe port_vlan_filtering · f05e2db1
      Florian Fainelli authored
      Described what the port_vlan_filtering function is supposed to
      accomplish.
      
      Fixes: fb2dabad ("net: dsa: support VLAN filtering switchdev attr")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f05e2db1
    • Florian Fainelli's avatar
      Documentation: networking: dsa: Remove priv_size description · 7013d8e1
      Florian Fainelli authored
      We no longer have a priv_size structure member since 5feebd0a ("net:
      dsa: Remove allocation of driver private memory")
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7013d8e1