1. 29 6月, 2016 1 次提交
    • F
      cfg80211: fix proto in ieee80211_data_to_8023 for frames without LLC header · c041778c
      Felix Fietkau 提交于
      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: NGerry Rozema <gerryr@rozeware.com>
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      c041778c
  2. 28 6月, 2016 1 次提交
    • J
      mac80211: Fix mesh estab_plinks counting in STA removal case · 126e7557
      Jouni Malinen 提交于
      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: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      126e7557
  3. 09 6月, 2016 2 次提交
    • P
      wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel · 3d5fdff4
      Prasun Maiti 提交于
      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: NPrasun Maiti <prasunmaiti87@gmail.com>
      Signed-off-by: NUjjal Roy <royujjal@gmail.com>
      Tested-by: NDibyajyoti Ghosh <dibyajyotig@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3d5fdff4
    • J
      cfg80211: remove get/set antenna and tx power warnings · 6cbf6236
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      6cbf6236
  4. 31 5月, 2016 2 次提交
    • F
      mac80211: fix fast_tx header alignment · 6fe04128
      Felix Fietkau 提交于
      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: NFelix Fietkau <nbd@nbd.name>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6fe04128
    • B
      mac80211: mesh: flush mesh paths unconditionally · fe7a7c57
      Bob Copeland 提交于
      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: NFred Veldini <fred.veldini@gmail.com>
      Tested-by: NFred Veldini <fred.veldini@gmail.com>
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fe7a7c57
  5. 30 5月, 2016 4 次提交
    • S
      net: l2tp: Make l2tp_ip6 namespace aware · 0e6b5259
      Shmulik Ladkani 提交于
      l2tp_ip6 tunnel and session lookups were still using init_net, although
      the l2tp core infrastructure already supports lookups keyed by 'net'.
      
      As a result, l2tp_ip6_recv discarded packets for tunnels/sessions
      created in namespaces other than the init_net.
      
      Fix, by using dev_net(skb->dev) or sock_net(sk) where appropriate.
      Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e6b5259
    • B
      ieee802154: fix logic error in ieee802154_llsec_parse_dev_addr · 421eeea1
      Baozeng Ding 提交于
      Fix a logic error to avoid potential null pointer dereference.
      Signed-off-by: NBaozeng Ding <sploving1@gmail.com>
      Reviewed-by: Stefan Schmidt<stefan@osg.samsung.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      421eeea1
    • A
      net/lapb: tuse %*ph to dump buffers · 0d08df6c
      Andy Shevchenko 提交于
      Use %*ph specifier to dump small buffers in hex format instead doing this
      byte-by-byte.
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d08df6c
    • A
      fou: add Kconfig options for IPv6 support · fabb13db
      Arnd Bergmann 提交于
      A previous patch added the fou6.ko module, but that failed to link
      in a couple of configurations:
      
      net/built-in.o: In function `ip6_tnl_encap_add_fou_ops':
      net/ipv6/fou6.c:88: undefined reference to `ip6_tnl_encap_add_ops'
      net/ipv6/fou6.c:94: undefined reference to `ip6_tnl_encap_add_ops'
      net/ipv6/fou6.c:97: undefined reference to `ip6_tnl_encap_del_ops'
      net/built-in.o: In function `ip6_tnl_encap_del_fou_ops':
      net/ipv6/fou6.c:106: undefined reference to `ip6_tnl_encap_del_ops'
      net/ipv6/fou6.c:107: undefined reference to `ip6_tnl_encap_del_ops'
      
      If CONFIG_IPV6=m, ip6_tnl_encap_add_ops/ip6_tnl_encap_del_ops
      are in a module, but fou6.c can still be built-in, and that
      obviously fails to link.
      
      Also, if CONFIG_IPV6=y, but CONFIG_IPV6_TUNNEL=m or
      CONFIG_IPV6_TUNNEL=n, the same problem happens for a different
      reason.
      
      This adds two new silent Kconfig symbols to work around both
      problems:
      
      - CONFIG_IPV6_FOU is now always set to 'm' if either CONFIG_NET_FOU=m
        or CONFIG_IPV6=m
      - CONFIG_IPV6_FOU_TUNNEL is set implicitly when IPV6_FOU is enabled
        and NET_FOU_IP_TUNNELS is also turned out, and it will ensure
        that CONFIG_IPV6_TUNNEL is also available.
      
      The options could be made user-visible as well, to give additional
      room for configuration, but it seems easier not to bother users
      with more choice here.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: aa3463d6 ("fou: Add encap ops for IPv6 tunnels")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fabb13db
  6. 26 5月, 2016 3 次提交
  7. 25 5月, 2016 4 次提交
  8. 24 5月, 2016 2 次提交
    • E
      ipv4: Fix non-initialized TTL when CONFIG_SYSCTL=n · 049bbf58
      Ezequiel Garcia 提交于
      Commit fa50d974 ("ipv4: Namespaceify ip_default_ttl sysctl knob")
      moves the default TTL assignment, and as side-effect IPv4 TTL now
      has a default value only if sysctl support is enabled (CONFIG_SYSCTL=y).
      
      The sysctl_ip_default_ttl is fundamental for IP to work properly,
      as it provides the TTL to be used as default. The defautl TTL may be
      used in ip_selected_ttl, through the following flow:
      
        ip_select_ttl
          ip4_dst_hoplimit
            net->ipv4.sysctl_ip_default_ttl
      
      This commit fixes the issue by assigning net->ipv4.sysctl_ip_default_ttl
      in net_init_net, called during ipv4's initialization.
      
      Without this commit, a kernel built without sysctl support will send
      all IP packets with zero TTL (unless a TTL is explicitly set, e.g.
      with setsockopt).
      
      Given a similar issue might appear on the other knobs that were
      namespaceify, this commit also moves them.
      
      Fixes: fa50d974 ("ipv4: Namespaceify ip_default_ttl sysctl knob")
      Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      049bbf58
    • S
      net/atm: sk_err_soft must be positive · c685293a
      Stefan Hajnoczi 提交于
      The sk_err and sk_err_soft fields are positive errno values and
      userspace applications rely on this when using getsockopt(SO_ERROR).
      
      ATM code places an -errno into sk_err_soft in sigd_send() and returns it
      from svc_addparty()/svc_dropparty().
      
      Although I am not familiar with ATM code I came to this conclusion
      because:
      
      1. sigd_send() msg->type cases as_okay and as_error both have:
      
         sk->sk_err = -msg->reply;
      
         while the as_addparty and as_dropparty cases have:
      
         sk->sk_err_soft = msg->reply;
      
         This is the source of the inconsistency.
      
      2. svc_addparty() returns an -errno and assumes sk_err_soft is also an
         -errno:
      
             if (flags & O_NONBLOCK) {
                 error = -EINPROGRESS;
                 goto out;
             }
             ...
             error = xchg(&sk->sk_err_soft, 0);
         out:
             release_sock(sk);
             return error;
      
         This shows that sk_err_soft is indeed being treated as an -errno.
      
      This patch ensures that sk_err_soft is always a positive errno.
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c685293a
  9. 21 5月, 2016 20 次提交
  10. 20 5月, 2016 1 次提交