1. 09 Dec, 2018 6 commits
  2. 08 Dec, 2018 5 commits
    • Benjamin Herrenschmidt's avatar
      Revert "net/ibm/emac: wrong bit is used for STA control" · 5b3279e2
      Benjamin Herrenschmidt authored
      This reverts commit 624ca9c3.
      
      This commit is completely bogus. The STACR register has two formats, old
      and new, depending on the version of the IP block used. There's a pair of
      device-tree properties that can be used to specify the format used:
      
      	has-inverted-stacr-oc
      	has-new-stacr-staopc
      
      What this commit did was to change the bit definition used with the old
      parts to match the new parts. This of course breaks the driver on all
      the old ones.
      
      Instead, the author should have set the appropriate properties in the
      device-tree for the variant used on his board.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b3279e2
    • David S. Miller's avatar
      Merge branch 'skb-headroom-slab-out-of-bounds' · 8b78903b
      David S. Miller authored
      Stefano Brivio says:
      
      ====================
      Fix slab out-of-bounds on insufficient headroom for IPv6 packets
      
      Patch 1/2 fixes a slab out-of-bounds occurring with short SCTP packets over
      IPv4 over L2TP over IPv6 on a configuration with relatively low HEADER_MAX.
      
      Patch 2/2 makes sure we avoid writing before the allocated buffer in
      neigh_hh_output() in case the headroom is enough for the unaligned hardware
      header size, but not enough for the aligned one, and that we warn if we hit
      this condition.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b78903b
    • Stefano Brivio's avatar
      neighbour: Avoid writing before skb->head in neigh_hh_output() · e6ac64d4
      Stefano Brivio authored
      While skb_push() makes the kernel panic if the skb headroom is less than
      the unaligned hardware header size, it will proceed normally in case we
      copy more than that because of alignment, and we'll silently corrupt
      adjacent slabs.
      
      In the case fixed by the previous patch,
      "ipv6: Check available headroom in ip6_xmit() even without options", we
      end up in neigh_hh_output() with 14 bytes headroom, 14 bytes hardware
      header and write 16 bytes, starting 2 bytes before the allocated buffer.
      
      Always check we're not writing before skb->head and, if the headroom is
      not enough, warn and drop the packet.
      
      v2:
       - instead of panicking with BUG_ON(), WARN_ON_ONCE() and drop the packet
         (Eric Dumazet)
       - if we avoid the panic, though, we need to explicitly check the headroom
         before the memcpy(), otherwise we'll have corrupted slabs on a running
         kernel, after we warn
       - use __skb_push() instead of skb_push(), as the headroom check is
         already implemented here explicitly (Eric Dumazet)
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6ac64d4
    • Stefano Brivio's avatar
      ipv6: Check available headroom in ip6_xmit() even without options · 66033f47
      Stefano Brivio authored
      Even if we send an IPv6 packet without options, MAX_HEADER might not be
      enough to account for the additional headroom required by alignment of
      hardware headers.
      
      On a configuration without HYPERV_NET, WLAN, AX25, and with IPV6_TUNNEL,
      sending short SCTP packets over IPv4 over L2TP over IPv6, we start with
      100 bytes of allocated headroom in sctp_packet_transmit(), end up with 54
      bytes after l2tp_xmit_skb(), and 14 bytes in ip6_finish_output2().
      
      Those would be enough to append our 14 bytes header, but we're going to
      align that to 16 bytes, and write 2 bytes out of the allocated slab in
      neigh_hh_output().
      
      KASan says:
      
      [  264.967848] ==================================================================
      [  264.967861] BUG: KASAN: slab-out-of-bounds in ip6_finish_output2+0x1aec/0x1c70
      [  264.967866] Write of size 16 at addr 000000006af1c7fe by task netperf/6201
      [  264.967870]
      [  264.967876] CPU: 0 PID: 6201 Comm: netperf Not tainted 4.20.0-rc4+ #1
      [  264.967881] Hardware name: IBM 2827 H43 400 (z/VM 6.4.0)
      [  264.967887] Call Trace:
      [  264.967896] ([<00000000001347d6>] show_stack+0x56/0xa0)
      [  264.967903]  [<00000000017e379c>] dump_stack+0x23c/0x290
      [  264.967912]  [<00000000007bc594>] print_address_description+0xf4/0x290
      [  264.967919]  [<00000000007bc8fc>] kasan_report+0x13c/0x240
      [  264.967927]  [<000000000162f5e4>] ip6_finish_output2+0x1aec/0x1c70
      [  264.967935]  [<000000000163f890>] ip6_finish_output+0x430/0x7f0
      [  264.967943]  [<000000000163fe44>] ip6_output+0x1f4/0x580
      [  264.967953]  [<000000000163882a>] ip6_xmit+0xfea/0x1ce8
      [  264.967963]  [<00000000017396e2>] inet6_csk_xmit+0x282/0x3f8
      [  264.968033]  [<000003ff805fb0ba>] l2tp_xmit_skb+0xe02/0x13e0 [l2tp_core]
      [  264.968037]  [<000003ff80631192>] l2tp_eth_dev_xmit+0xda/0x150 [l2tp_eth]
      [  264.968041]  [<0000000001220020>] dev_hard_start_xmit+0x268/0x928
      [  264.968069]  [<0000000001330e8e>] sch_direct_xmit+0x7ae/0x1350
      [  264.968071]  [<000000000122359c>] __dev_queue_xmit+0x2b7c/0x3478
      [  264.968075]  [<00000000013d2862>] ip_finish_output2+0xce2/0x11a0
      [  264.968078]  [<00000000013d9b14>] ip_finish_output+0x56c/0x8c8
      [  264.968081]  [<00000000013ddd1e>] ip_output+0x226/0x4c0
      [  264.968083]  [<00000000013dbd6c>] __ip_queue_xmit+0x894/0x1938
      [  264.968100]  [<000003ff80bc3a5c>] sctp_packet_transmit+0x29d4/0x3648 [sctp]
      [  264.968116]  [<000003ff80b7bf68>] sctp_outq_flush_ctrl.constprop.5+0x8d0/0xe50 [sctp]
      [  264.968131]  [<000003ff80b7c716>] sctp_outq_flush+0x22e/0x7d8 [sctp]
      [  264.968146]  [<000003ff80b35c68>] sctp_cmd_interpreter.isra.16+0x530/0x6800 [sctp]
      [  264.968161]  [<000003ff80b3410a>] sctp_do_sm+0x222/0x648 [sctp]
      [  264.968177]  [<000003ff80bbddac>] sctp_primitive_ASSOCIATE+0xbc/0xf8 [sctp]
      [  264.968192]  [<000003ff80b93328>] __sctp_connect+0x830/0xc20 [sctp]
      [  264.968208]  [<000003ff80bb11ce>] sctp_inet_connect+0x2e6/0x378 [sctp]
      [  264.968212]  [<0000000001197942>] __sys_connect+0x21a/0x450
      [  264.968215]  [<000000000119aff8>] sys_socketcall+0x3d0/0xb08
      [  264.968218]  [<000000000184ea7a>] system_call+0x2a2/0x2c0
      
      [...]
      
      Just like ip_finish_output2() does for IPv4, check that we have enough
      headroom in ip6_xmit(), and reallocate it if we don't.
      
      This issue is older than git history.
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66033f47
    • Eric Dumazet's avatar
      tcp: lack of available data can also cause TSO defer · f9bfe4e6
      Eric Dumazet authored
      tcp_tso_should_defer() can return true in three different cases :
      
       1) We are cwnd-limited
       2) We are rwnd-limited
       3) We are application limited.
      
      Neal pointed out that my recent fix went too far, since
      it assumed that if we were not in 1) case, we must be rwnd-limited
      
      Fix this by properly populating the is_cwnd_limited and
      is_rwnd_limited booleans.
      
      After this change, we can finally move the silly check for FIN
      flag only for the application-limited case.
      
      The same move for EOR bit will be handled in net-next,
      since commit 1c09f7d0 ("tcp: do not try to defer skbs
      with eor mark (MSG_EOR)") is scheduled for linux-4.21
      
      Tested by running 200 concurrent netperf -t TCP_RR -- -r 60000,100
      and checking none of them was rwnd_limited in the chrono_stat
      output from "ss -ti" command.
      
      Fixes: 41727549 ("tcp: Do not underestimate rwnd_limited")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Suggested-by: default avatarNeal Cardwell <ncardwell@google.com>
      Reviewed-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Reviewed-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9bfe4e6
  3. 07 Dec, 2018 1 commit
  4. 06 Dec, 2018 11 commits
    • David S. Miller's avatar
      Merge branch 'mlxsw-Various-fixes' · cd9d1a23
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Various fixes
      
      Patches #1 and #2 fix two VxLAN related issues. The first patch removes
      warnings that can currently be triggered from user space. Second patch
      avoids leaking a FID in an error path.
      
      Patch #3 fixes a too strict check that causes certain host routes not to
      be promoted to perform GRE decapsulation in hardware.
      
      Last patch avoids a use-after-free when deleting a VLAN device via an
      ioctl when it is enslaved to a bridge. I have a patchset for net-next
      that reworks this code and makes the driver more robust.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd9d1a23
    • Ido Schimmel's avatar
      mlxsw: spectrum_switchdev: Fix VLAN device deletion via ioctl · 993107fe
      Ido Schimmel authored
      When deleting a VLAN device using an ioctl the netdev is unregistered
      before the VLAN filter is updated via ndo_vlan_rx_kill_vid(). It can
      lead to a use-after-free in mlxsw in case the VLAN device is deleted
      while being enslaved to a bridge.
      
      The reason for the above is that when mlxsw receives the CHANGEUPPER
      event, it wrongly assumes that the VLAN device is no longer its upper
      and thus destroys the internal representation of the bridge port despite
      the reference count being non-zero.
      
      Fix this by checking if the VLAN device is our upper using its real
      device. In net-next I'm going to remove this trick and instead make
      mlxsw completely agnostic to the order of the events.
      
      Fixes: c57529e1 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      993107fe
    • Nir Dotan's avatar
      mlxsw: spectrum_router: Relax GRE decap matching check · da93d291
      Nir Dotan authored
      GRE decap offload is configured when local routes prefix correspond to the
      local address of one of the offloaded GRE tunnels. The matching check was
      found to be too strict, such that for a flat GRE configuration, in which
      the overlay and underlay traffic share the same non-default VRF, decap flow
      was not offloaded.
      
      Relax the check for decap flow offloading. A match occurs if the local
      address of the tunnel matches the local route address while both share the
      same VRF table.
      
      Fixes: 4607f6d2 ("mlxsw: spectrum_router: Support IPv4 underlay decap")
      Signed-off-by: default avatarNir Dotan <nird@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      da93d291
    • Ido Schimmel's avatar
      mlxsw: spectrum_switchdev: Avoid leaking FID's reference count · f58a83c2
      Ido Schimmel authored
      It should never be possible for a user to set a VNI on a FID in case one
      is already set. The driver therefore returns an error, but fails to drop
      the reference count taken earlier when calling
      mlxsw_sp_fid_8021d_lookup().
      
      Drop the reference when this unlikely error is hit.
      
      Fixes: 1c30d183 ("mlxsw: spectrum: Enable VxLAN enslavement to bridges")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f58a83c2
    • Ido Schimmel's avatar
      mlxsw: spectrum_nve: Remove easily triggerable warnings · 050fc01f
      Ido Schimmel authored
      It is possible to trigger a warning in mlxsw in case a flood entry which
      mlxsw is not aware of is deleted from the VxLAN device. This is because
      mlxsw expects to find a singly linked list where the flood entry is
      present in.
      
      Fix by removing these warnings for now.
      
      Will re-add them in the next release after we teach mlxsw to ask for a
      dump of FDB entries from the VxLAN device, once it is enslaved to a
      bridge mlxsw cares about.
      
      Fixes: 6e6030bd ("mlxsw: spectrum_nve: Implement common NVE core")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      050fc01f
    • Jiri Wiesner's avatar
      ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes · ebaf39e6
      Jiri Wiesner authored
      The *_frag_reasm() functions are susceptible to miscalculating the byte
      count of packet fragments in case the truesize of a head buffer changes.
      The truesize member may be changed by the call to skb_unclone(), leaving
      the fragment memory limit counter unbalanced even if all fragments are
      processed. This miscalculation goes unnoticed as long as the network
      namespace which holds the counter is not destroyed.
      
      Should an attempt be made to destroy a network namespace that holds an
      unbalanced fragment memory limit counter the cleanup of the namespace
      never finishes. The thread handling the cleanup gets stuck in
      inet_frags_exit_net() waiting for the percpu counter to reach zero. The
      thread is usually in running state with a stacktrace similar to:
      
       PID: 1073   TASK: ffff880626711440  CPU: 1   COMMAND: "kworker/u48:4"
        #5 [ffff880621563d48] _raw_spin_lock at ffffffff815f5480
        #6 [ffff880621563d48] inet_evict_bucket at ffffffff8158020b
        #7 [ffff880621563d80] inet_frags_exit_net at ffffffff8158051c
        #8 [ffff880621563db0] ops_exit_list at ffffffff814f5856
        #9 [ffff880621563dd8] cleanup_net at ffffffff814f67c0
       #10 [ffff880621563e38] process_one_work at ffffffff81096f14
      
      It is not possible to create new network namespaces, and processes
      that call unshare() end up being stuck in uninterruptible sleep state
      waiting to acquire the net_mutex.
      
      The bug was observed in the IPv6 netfilter code by Per Sundstrom.
      I thank him for his analysis of the problem. The parts of this patch
      that apply to IPv4 and IPv6 fragment reassembly are preemptive measures.
      Signed-off-by: default avatarJiri Wiesner <jwiesner@suse.com>
      Reported-by: default avatarPer Sundstrom <per.sundstrom@redqube.se>
      Acked-by: default avatarPeter Oskolkov <posk@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebaf39e6
    • Jakub Audykowicz's avatar
      sctp: frag_point sanity check · afd0a800
      Jakub Audykowicz authored
      If for some reason an association's fragmentation point is zero,
      sctp_datamsg_from_user will try to endlessly try to divide a message
      into zero-sized chunks. This eventually causes kernel panic due to
      running out of memory.
      
      Although this situation is quite unlikely, it has occurred before as
      reported. I propose to add this simple last-ditch sanity check due to
      the severity of the potential consequences.
      Signed-off-by: default avatarJakub Audykowicz <jakub.audykowicz@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      afd0a800
    • Yuchung Cheng's avatar
      tcp: fix NULL ref in tail loss probe · b2b7af86
      Yuchung Cheng authored
      TCP loss probe timer may fire when the retranmission queue is empty but
      has a non-zero tp->packets_out counter. tcp_send_loss_probe will call
      tcp_rearm_rto which triggers NULL pointer reference by fetching the
      retranmission queue head in its sub-routines.
      
      Add a more detailed warning to help catch the root cause of the inflight
      accounting inconsistency.
      Reported-by: default avatarRafael Tinoco <rafael.tinoco@linaro.org>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b2b7af86
    • Eric Dumazet's avatar
      tcp: Do not underestimate rwnd_limited · 41727549
      Eric Dumazet authored
      If available rwnd is too small, tcp_tso_should_defer()
      can decide it is worth waiting before splitting a TSO packet.
      
      This really means we are rwnd limited.
      
      Fixes: 5615f886 ("tcp: instrument how long TCP is limited by receive window")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Reviewed-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41727549
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · e37d05a5
      David S. Miller authored
      Alexei Starovoitov says:
      
      ====================
      pull-request: bpf 2018-12-05
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) fix bpf uapi pointers for 32-bit architectures, from Daniel.
      
      2) improve verifer ability to handle progs with a lot of branches, from Alexei.
      
      3) strict btf checks, from Yonghong.
      
      4) bpf_sk_lookup api cleanup, from Joe.
      
      5) other misc fixes
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e37d05a5
    • Edward Cree's avatar
      net: use skb_list_del_init() to remove from RX sublists · 22f6bbb7
      Edward Cree authored
      list_del() leaves the skb->next pointer poisoned, which can then lead to
       a crash in e.g. OVS forwarding.  For example, setting up an OVS VXLAN
       forwarding bridge on sfc as per:
      
      ========
      $ ovs-vsctl show
      5dfd9c47-f04b-4aaa-aa96-4fbb0a522a30
          Bridge "br0"
              Port "br0"
                  Interface "br0"
                      type: internal
              Port "enp6s0f0"
                  Interface "enp6s0f0"
              Port "vxlan0"
                  Interface "vxlan0"
                      type: vxlan
                      options: {key="1", local_ip="10.0.0.5", remote_ip="10.0.0.4"}
          ovs_version: "2.5.0"
      ========
      (where 10.0.0.5 is an address on enp6s0f1)
      and sending traffic across it will lead to the following panic:
      ========
      general protection fault: 0000 [#1] SMP PTI
      CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.20.0-rc3-ehc+ #701
      Hardware name: Dell Inc. PowerEdge R710/0M233H, BIOS 6.4.0 07/23/2013
      RIP: 0010:dev_hard_start_xmit+0x38/0x200
      Code: 53 48 89 fb 48 83 ec 20 48 85 ff 48 89 54 24 08 48 89 4c 24 18 0f 84 ab 01 00 00 48 8d 86 90 00 00 00 48 89 f5 48 89 44 24 10 <4c> 8b 33 48 c7 03 00 00 00 00 48 8b 05 c7 d1 b3 00 4d 85 f6 0f 95
      RSP: 0018:ffff888627b437e0 EFLAGS: 00010202
      RAX: 0000000000000000 RBX: dead000000000100 RCX: ffff88862279c000
      RDX: ffff888614a342c0 RSI: 0000000000000000 RDI: 0000000000000000
      RBP: ffff888618a88000 R08: 0000000000000001 R09: 00000000000003e8
      R10: 0000000000000000 R11: ffff888614a34140 R12: 0000000000000000
      R13: 0000000000000062 R14: dead000000000100 R15: ffff888616430000
      FS:  0000000000000000(0000) GS:ffff888627b40000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f6d2bc6d000 CR3: 000000000200a000 CR4: 00000000000006e0
      Call Trace:
       <IRQ>
       __dev_queue_xmit+0x623/0x870
       ? masked_flow_lookup+0xf7/0x220 [openvswitch]
       ? ep_poll_callback+0x101/0x310
       do_execute_actions+0xaba/0xaf0 [openvswitch]
       ? __wake_up_common+0x8a/0x150
       ? __wake_up_common_lock+0x87/0xc0
       ? queue_userspace_packet+0x31c/0x5b0 [openvswitch]
       ovs_execute_actions+0x47/0x120 [openvswitch]
       ovs_dp_process_packet+0x7d/0x110 [openvswitch]
       ovs_vport_receive+0x6e/0xd0 [openvswitch]
       ? dst_alloc+0x64/0x90
       ? rt_dst_alloc+0x50/0xd0
       ? ip_route_input_slow+0x19a/0x9a0
       ? __udp_enqueue_schedule_skb+0x198/0x1b0
       ? __udp4_lib_rcv+0x856/0xa30
       ? __udp4_lib_rcv+0x856/0xa30
       ? cpumask_next_and+0x19/0x20
       ? find_busiest_group+0x12d/0xcd0
       netdev_frame_hook+0xce/0x150 [openvswitch]
       __netif_receive_skb_core+0x205/0xae0
       __netif_receive_skb_list_core+0x11e/0x220
       netif_receive_skb_list+0x203/0x460
       ? __efx_rx_packet+0x335/0x5e0 [sfc]
       efx_poll+0x182/0x320 [sfc]
       net_rx_action+0x294/0x3c0
       __do_softirq+0xca/0x297
       irq_exit+0xa6/0xb0
       do_IRQ+0x54/0xd0
       common_interrupt+0xf/0xf
       </IRQ>
      ========
      So, in all listified-receive handling, instead pull skbs off the lists with
       skb_list_del_init().
      
      Fixes: 9af86f93 ("net: core: fix use-after-free in __netif_receive_skb_list_core")
      Fixes: 7da517a3 ("net: core: Another step of skb receive list processing")
      Fixes: a4ca8b7d ("net: ipv4: fix drop handling in ip_list_rcv() and ip_list_rcv_finish()")
      Fixes: d8269e2c ("net: ipv6: listify ipv6_rcv() and ip6_rcv_finish()")
      Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22f6bbb7
  5. 05 Dec, 2018 9 commits
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2018-12-05' of... · 64d47902
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2018-12-05' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg:
      
      ====================
      As it's been a while, we have various fixes for
       * hwsim
       * AP mode (client powersave related)
       * CSA/FTM interaction
       * a busy loop in IE handling
       * and similar
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64d47902
    • Jouni Malinen's avatar
      cfg80211: Fix busy loop regression in ieee80211_ie_split_ric() · 312ca38d
      Jouni Malinen authored
      This function was modified to support the information element extension
      case (WLAN_EID_EXTENSION) in a manner that would result in an infinite
      loop when going through set of IEs that include WLAN_EID_RIC_DATA and
      contain an IE that is in the after_ric array. The only place where this
      can currently happen is in mac80211 ieee80211_send_assoc() where
      ieee80211_ie_split_ric() is called with after_ric[].
      
      This can be triggered by valid data from user space nl80211
      association/connect request (i.e., requiring GENL_UNS_ADMIN_PERM). The
      only known application having an option to include WLAN_EID_RIC_DATA in
      these requests is wpa_supplicant and it had a bug that prevented this
      specific contents from being used (and because of that, not triggering
      this kernel bug in an automated test case ap_ft_ric) and now that this
      bug is fixed, it has a workaround to avoid this kernel issue.
      WLAN_EID_RIC_DATA is currently used only for testing purposes, so this
      does not cause significant harm for production use cases.
      
      Fixes: 2512b1b1 ("mac80211: extend ieee80211_ie_split to support EXTENSION")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJouni Malinen <jouni@codeaurora.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      312ca38d
    • Emmanuel Grumbach's avatar
      mac80211: ignore NullFunc frames in the duplicate detection · 990d7184
      Emmanuel Grumbach authored
      NullFunc packets should never be duplicate just like
      QoS-NullFunc packets.
      
      We saw a client that enters / exits power save with
      NullFunc frames (and not with QoS-NullFunc) despite the
      fact that the association supports HT.
      This specific client also re-uses a non-zero sequence number
      for different NullFunc frames.
      At some point, the client had to send a retransmission of
      the NullFunc frame and we dropped it, leading to a
      misalignment in the power save state.
      Fix this by never consider a NullFunc frame as duplicate,
      just like we do for QoS NullFunc frames.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      990d7184
    • Felix Fietkau's avatar
      mac80211: fix reordering of buffered broadcast packets · 9ec1190d
      Felix Fietkau authored
      If the buffered broadcast queue contains packets, letting new packets bypass
      that queue can lead to heavy reordering, since the driver is probably throttling
      transmission of buffered multicast packets after beacons.
      
      Keep buffering packets until the buffer has been cleared (and no client
      is in powersave mode).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      9ec1190d
    • Felix Fietkau's avatar
      mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext · a317e65f
      Felix Fietkau authored
      Make it behave like regular ieee80211_tx_status calls, except for the lack of
      filtered frame processing.
      This fixes spurious low-ack triggered disconnections with powersave clients
      connected to an AP.
      
      Fixes: f027c2ac ("mac80211: add ieee80211_tx_status_noskb")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a317e65f
    • Baruch Siach's avatar
      net: mvpp2: fix phylink handling of invalid PHY modes · 0fb628f0
      Baruch Siach authored
      The .validate phylink callback should empty the supported bitmap when
      the interface mode is invalid.
      
      Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
      Cc: Antoine Tenart <antoine.tenart@bootlin.com>
      Reported-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fb628f0
    • Baruch Siach's avatar
      net: mvpp2: fix detection of 10G SFP modules · 01b3fd5a
      Baruch Siach authored
      The mvpp2_phylink_validate() relies on the interface field of
      phylink_link_state to determine valid link modes. However, when called
      from phylink_sfp_module_insert() this field in not initialized. The
      default switch case then excludes 10G link modes. This allows 10G SFP
      modules that are detected correctly to be configured at max rate of
      2.5G.
      
      Catch the uninitialized PHY mode case, and allow 10G rates.
      
      Fixes: d97c9f4a ("net: mvpp2: 1000baseX support")
      Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
      Cc: Antoine Tenart <antoine.tenart@bootlin.com>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      01b3fd5a
    • Nicolas Saenz Julienne's avatar
      ethernet: fman: fix wrong of_node_put() in probe function · ecb239d9
      Nicolas Saenz Julienne authored
      After getting a reference to the platform device's of_node the probe
      function ends up calling of_find_matching_node() using the node as an
      argument. The function takes care of decreasing the refcount on it. We
      are then incorrectly decreasing the refcount on that node again.
      
      This patch removes the unwarranted call to of_node_put().
      
      Fixes: 414fd46e ("fsl/fman: Add FMan support")
      Signed-off-by: default avatarNicolas Saenz Julienne <nsaenzjulienne@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ecb239d9
    • Eric Dumazet's avatar
      rtnetlink: ndo_dflt_fdb_dump() only work for ARPHRD_ETHER devices · 68883893
      Eric Dumazet authored
      kmsan was able to trigger a kernel-infoleak using a gre device [1]
      
      nlmsg_populate_fdb_fill() has a hard coded assumption
      that dev->addr_len is ETH_ALEN, as normally guaranteed
      for ARPHRD_ETHER devices.
      
      A similar issue was fixed recently in commit da715775
      ("rtnetlink: Disallow FDB configuration for non-Ethernet device")
      
      [1]
      BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:143 [inline]
      BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576
      CPU: 0 PID: 6697 Comm: syz-executor310 Not tainted 4.20.0-rc3+ #95
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x32d/0x480 lib/dump_stack.c:113
       kmsan_report+0x12c/0x290 mm/kmsan/kmsan.c:683
       kmsan_internal_check_memory+0x32a/0xa50 mm/kmsan/kmsan.c:743
       kmsan_copy_to_user+0x78/0xd0 mm/kmsan/kmsan_hooks.c:634
       copyout lib/iov_iter.c:143 [inline]
       _copy_to_iter+0x4c0/0x2700 lib/iov_iter.c:576
       copy_to_iter include/linux/uio.h:143 [inline]
       skb_copy_datagram_iter+0x4e2/0x1070 net/core/datagram.c:431
       skb_copy_datagram_msg include/linux/skbuff.h:3316 [inline]
       netlink_recvmsg+0x6f9/0x19d0 net/netlink/af_netlink.c:1975
       sock_recvmsg_nosec net/socket.c:794 [inline]
       sock_recvmsg+0x1d1/0x230 net/socket.c:801
       ___sys_recvmsg+0x444/0xae0 net/socket.c:2278
       __sys_recvmsg net/socket.c:2327 [inline]
       __do_sys_recvmsg net/socket.c:2337 [inline]
       __se_sys_recvmsg+0x2fa/0x450 net/socket.c:2334
       __x64_sys_recvmsg+0x4a/0x70 net/socket.c:2334
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x441119
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fffc7f008a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002f
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441119
      RDX: 0000000000000040 RSI: 00000000200005c0 RDI: 0000000000000003
      RBP: 00000000006cc018 R08: 0000000000000100 R09: 0000000000000100
      R10: 0000000000000100 R11: 0000000000000207 R12: 0000000000402080
      R13: 0000000000402110 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
       kmsan_save_stack mm/kmsan/kmsan.c:261 [inline]
       kmsan_internal_chain_origin+0x13d/0x240 mm/kmsan/kmsan.c:469
       kmsan_memcpy_memmove_metadata+0x1a9/0xf70 mm/kmsan/kmsan.c:344
       kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:362
       __msan_memcpy+0x61/0x70 mm/kmsan/kmsan_instr.c:162
       __nla_put lib/nlattr.c:744 [inline]
       nla_put+0x20a/0x2d0 lib/nlattr.c:802
       nlmsg_populate_fdb_fill+0x444/0x810 net/core/rtnetlink.c:3466
       nlmsg_populate_fdb net/core/rtnetlink.c:3775 [inline]
       ndo_dflt_fdb_dump+0x73a/0x960 net/core/rtnetlink.c:3807
       rtnl_fdb_dump+0x1318/0x1cb0 net/core/rtnetlink.c:3979
       netlink_dump+0xc79/0x1c90 net/netlink/af_netlink.c:2244
       __netlink_dump_start+0x10c4/0x11d0 net/netlink/af_netlink.c:2352
       netlink_dump_start include/linux/netlink.h:216 [inline]
       rtnetlink_rcv_msg+0x141b/0x1540 net/core/rtnetlink.c:4910
       netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116
       __sys_sendmsg net/socket.c:2154 [inline]
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
       kmsan_internal_poison_shadow+0x6d/0x130 mm/kmsan/kmsan.c:170
       kmsan_kmalloc+0xa1/0x100 mm/kmsan/kmsan_hooks.c:186
       __kmalloc+0x14c/0x4d0 mm/slub.c:3825
       kmalloc include/linux/slab.h:551 [inline]
       __hw_addr_create_ex net/core/dev_addr_lists.c:34 [inline]
       __hw_addr_add_ex net/core/dev_addr_lists.c:80 [inline]
       __dev_mc_add+0x357/0x8a0 net/core/dev_addr_lists.c:670
       dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
       ip_mc_filter_add net/ipv4/igmp.c:1128 [inline]
       igmp_group_added+0x4d4/0xb80 net/ipv4/igmp.c:1311
       __ip_mc_inc_group+0xea9/0xf70 net/ipv4/igmp.c:1444
       ip_mc_inc_group net/ipv4/igmp.c:1453 [inline]
       ip_mc_up+0x1c3/0x400 net/ipv4/igmp.c:1775
       inetdev_event+0x1d03/0x1d80 net/ipv4/devinet.c:1522
       notifier_call_chain kernel/notifier.c:93 [inline]
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x13d/0x240 kernel/notifier.c:401
       __dev_notify_flags+0x3da/0x860 net/core/dev.c:1733
       dev_change_flags+0x1ac/0x230 net/core/dev.c:7569
       do_setlink+0x165f/0x5ea0 net/core/rtnetlink.c:2492
       rtnl_newlink+0x2ad7/0x35a0 net/core/rtnetlink.c:3111
       rtnetlink_rcv_msg+0x1148/0x1540 net/core/rtnetlink.c:4947
       netlink_rcv_skb+0x394/0x640 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4965
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x1699/0x1740 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x13c7/0x1440 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg net/socket.c:631 [inline]
       ___sys_sendmsg+0xe3b/0x1240 net/socket.c:2116
       __sys_sendmsg net/socket.c:2154 [inline]
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg+0x305/0x460 net/socket.c:2161
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161
       do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      Bytes 36-37 of 105 are uninitialized
      Memory access of size 105 starts at ffff88819686c000
      Data copied to user address 0000000020000380
      
      Fixes: d83b0603 ("net: add fdb generic dump routine")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Ido Schimmel <idosch@mellanox.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68883893
  6. 04 Dec, 2018 8 commits