1. 04 Nov, 2018 13 commits
    • Karsten Graul's avatar
      net/smc: fix smc_buf_unuse to use the lgr pointer · c3f13a4d
      Karsten Graul authored
      [ Upstream commit fb692ec4 ]
      
      The pointer to the link group is unset in the smc connection structure
      right before the call to smc_buf_unuse. Provide the lgr pointer to
      smc_buf_unuse explicitly.
      And move the call to smc_lgr_schedule_free_work to the end of
      smc_conn_free.
      
      Fixes: a6920d1d ("net/smc: handle unregistered buffers")
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3f13a4d
    • David Ahern's avatar
      net/ipv6: Allow onlink routes to have a device mismatch if it is the default route · 6a4aa53a
      David Ahern authored
      [ Upstream commit 4ed591c8 ]
      
      The intent of ip6_route_check_nh_onlink is to make sure the gateway
      given for an onlink route is not actually on a connected route for
      a different interface (e.g., 2001:db8:1::/64 is on dev eth1 and then
      an onlink route has a via 2001:db8:1::1 dev eth2). If the gateway
      lookup hits the default route then it most likely will be a different
      interface than the onlink route which is ok.
      
      Update ip6_route_check_nh_onlink to disregard the device mismatch
      if the gateway lookup hits the default route. Turns out the existing
      onlink tests are passing because there is no default route or it is
      an unreachable default, so update the onlink tests to have a default
      route other than unreachable.
      
      Fixes: fc1e64e1 ("net/ipv6: Add support for onlink flag")
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a4aa53a
    • Jaime Caamaño Ruiz's avatar
      openvswitch: Fix push/pop ethernet validation · 0024aeb0
      Jaime Caamaño Ruiz authored
      [ Upstream commit 46ebe283 ]
      
      When there are both pop and push ethernet header actions among the
      actions to be applied to a packet, an unexpected EINVAL (Invalid
      argument) error is obtained. This is due to mac_proto not being reset
      correctly when those actions are validated.
      
      Reported-at:
      https://mail.openvswitch.org/pipermail/ovs-discuss/2018-October/047554.html
      Fixes: 91820da6 ("openvswitch: add Ethernet push and pop actions")
      Signed-off-by: default avatarJaime Caamaño Ruiz <jcaamano@suse.com>
      Tested-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0024aeb0
    • Tobias Jungel's avatar
      bonding: fix length of actor system · 655b0860
      Tobias Jungel authored
      [ Upstream commit 414dd6fb ]
      
      The attribute IFLA_BOND_AD_ACTOR_SYSTEM is sent to user space having the
      length of sizeof(bond->params.ad_actor_system) which is 8 byte. This
      patch aligns the length to ETH_ALEN to have the same MAC address exposed
      as using sysfs.
      
      Fixes: f87fda00 ("bonding: prevent out of bound accesses")
      Signed-off-by: default avatarTobias Jungel <tobias.jungel@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      655b0860
    • Jason Wang's avatar
      vhost: Fix Spectre V1 vulnerability · 26ab2eb8
      Jason Wang authored
      [ Upstream commit ff002269 ]
      
      The idx in vhost_vring_ioctl() was controlled by userspace, hence a
      potential exploitation of the Spectre variant 1 vulnerability.
      
      Fixing this by sanitizing idx before using it to index d->vqs.
      
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      26ab2eb8
    • Ido Schimmel's avatar
      rtnetlink: Disallow FDB configuration for non-Ethernet device · 2799b518
      Ido Schimmel authored
      [ Upstream commit da715775 ]
      
      When an FDB entry is configured, the address is validated to have the
      length of an Ethernet address, but the device for which the address is
      configured can be of any type.
      
      The above can result in the use of uninitialized memory when the address
      is later compared against existing addresses since 'dev->addr_len' is
      used and it may be greater than ETH_ALEN, as with ip6tnl devices.
      
      Fix this by making sure that FDB entries are only configured for
      Ethernet devices.
      
      BUG: KMSAN: uninit-value in memcmp+0x11d/0x180 lib/string.c:863
      CPU: 1 PID: 4318 Comm: syz-executor998 Not tainted 4.19.0-rc3+ #49
      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+0x14b/0x190 lib/dump_stack.c:113
        kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
        __msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
        memcmp+0x11d/0x180 lib/string.c:863
        dev_uc_add_excl+0x165/0x7b0 net/core/dev_addr_lists.c:464
        ndo_dflt_fdb_add net/core/rtnetlink.c:3463 [inline]
        rtnl_fdb_add+0x1081/0x1270 net/core/rtnetlink.c:3558
        rtnetlink_rcv_msg+0xa0b/0x1530 net/core/rtnetlink.c:4715
        netlink_rcv_skb+0x36e/0x5f0 net/netlink/af_netlink.c:2454
        rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4733
        netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
        netlink_unicast+0x1638/0x1720 net/netlink/af_netlink.c:1343
        netlink_sendmsg+0x1205/0x1290 net/netlink/af_netlink.c:1908
        sock_sendmsg_nosec net/socket.c:621 [inline]
        sock_sendmsg net/socket.c:631 [inline]
        ___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
        __sys_sendmsg net/socket.c:2152 [inline]
        __do_sys_sendmsg net/socket.c:2161 [inline]
        __se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
        __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
        do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
        entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x440ee9
      Code: e8 cc ab 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 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 bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fff6a93b518 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000440ee9
      RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000003
      RBP: 0000000000000000 R08: 00000000004002c8 R09: 00000000004002c8
      R10: 00000000004002c8 R11: 0000000000000213 R12: 000000000000b4b0
      R13: 0000000000401ec0 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was created at:
        kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
        kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:181
        kmsan_kmalloc+0x98/0x100 mm/kmsan/kmsan_hooks.c:91
        kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:100
        slab_post_alloc_hook mm/slab.h:446 [inline]
        slab_alloc_node mm/slub.c:2718 [inline]
        __kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4351
        __kmalloc_reserve net/core/skbuff.c:138 [inline]
        __alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
        alloc_skb include/linux/skbuff.h:996 [inline]
        netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
        netlink_sendmsg+0xb49/0x1290 net/netlink/af_netlink.c:1883
        sock_sendmsg_nosec net/socket.c:621 [inline]
        sock_sendmsg net/socket.c:631 [inline]
        ___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
        __sys_sendmsg net/socket.c:2152 [inline]
        __do_sys_sendmsg net/socket.c:2161 [inline]
        __se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
        __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
        do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
        entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      v2:
      * Make error message more specific (David)
      
      Fixes: 090096bf ("net: generic fdb support for drivers without ndo_fdb_<op>")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-and-tested-by: syzbot+3a288d5f5530b901310e@syzkaller.appspotmail.com
      Reported-and-tested-by: syzbot+d53ab4e92a1db04110ff@syzkaller.appspotmail.com
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2799b518
    • Karsten Graul's avatar
      Revert "net: simplify sock_poll_wait" · fd54c188
      Karsten Graul authored
      [ Upstream commit 89ab066d ]
      
      This reverts commit dd979b4d.
      
      This broke tcp_poll for SMC fallback: An AF_SMC socket establishes an
      internal TCP socket for the initial handshake with the remote peer.
      Whenever the SMC connection can not be established this TCP socket is
      used as a fallback. All socket operations on the SMC socket are then
      forwarded to the TCP socket. In case of poll, the file->private_data
      pointer references the SMC socket because the TCP socket has no file
      assigned. This causes tcp_poll to wait on the wrong socket.
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd54c188
    • Sean Tranchetti's avatar
      net: udp: fix handling of CHECKSUM_COMPLETE packets · 4fb0dc97
      Sean Tranchetti authored
      [ Upstream commit db4f1be3 ]
      
      Current handling of CHECKSUM_COMPLETE packets by the UDP stack is
      incorrect for any packet that has an incorrect checksum value.
      
      udp4/6_csum_init() will both make a call to
      __skb_checksum_validate_complete() to initialize/validate the csum
      field when receiving a CHECKSUM_COMPLETE packet. When this packet
      fails validation, skb->csum will be overwritten with the pseudoheader
      checksum so the packet can be fully validated by software, but the
      skb->ip_summed value will be left as CHECKSUM_COMPLETE so that way
      the stack can later warn the user about their hardware spewing bad
      checksums. Unfortunately, leaving the SKB in this state can cause
      problems later on in the checksum calculation.
      
      Since the the packet is still marked as CHECKSUM_COMPLETE,
      udp_csum_pull_header() will SUBTRACT the checksum of the UDP header
      from skb->csum instead of adding it, leaving us with a garbage value
      in that field. Once we try to copy the packet to userspace in the
      udp4/6_recvmsg(), we'll make a call to skb_copy_and_csum_datagram_msg()
      to checksum the packet data and add it in the garbage skb->csum value
      to perform our final validation check.
      
      Since the value we're validating is not the proper checksum, it's possible
      that the folded value could come out to 0, causing us not to drop the
      packet. Instead, we believe that the packet was checksummed incorrectly
      by hardware since skb->ip_summed is still CHECKSUM_COMPLETE, and we attempt
      to warn the user with netdev_rx_csum_fault(skb->dev);
      
      Unfortunately, since this is the UDP path, skb->dev has been overwritten
      by skb->dev_scratch and is no longer a valid pointer, so we end up
      reading invalid memory.
      
      This patch addresses this problem in two ways:
      	1) Do not use the dev pointer when calling netdev_rx_csum_fault()
      	   from skb_copy_and_csum_datagram_msg(). Since this gets called
      	   from the UDP path where skb->dev has been overwritten, we have
      	   no way of knowing if the pointer is still valid. Also for the
      	   sake of consistency with the other uses of
      	   netdev_rx_csum_fault(), don't attempt to call it if the
      	   packet was checksummed by software.
      
      	2) Add better CHECKSUM_COMPLETE handling to udp4/6_csum_init().
      	   If we receive a packet that's CHECKSUM_COMPLETE that fails
      	   verification (i.e. skb->csum_valid == 0), check who performed
      	   the calculation. It's possible that the checksum was done in
      	   software by the network stack earlier (such as Netfilter's
      	   CONNTRACK module), and if that says the checksum is bad,
      	   we can drop the packet immediately instead of waiting until
      	   we try and copy it to userspace. Otherwise, we need to
      	   mark the SKB as CHECKSUM_NONE, since the skb->csum field
      	   no longer contains the full packet checksum after the
      	   call to __skb_checksum_validate_complete().
      
      Fixes: e6afc8ac ("udp: remove headers from UDP packets before queueing")
      Fixes: c84d9490 ("udp: copy skb->truesize in the first cache line")
      Cc: Sam Kumar <samanthakumar@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarSean Tranchetti <stranche@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fb0dc97
    • Niklas Cassel's avatar
      net: stmmac: Fix stmmac_mdio_reset() when building stmmac as modules · b4f003cb
      Niklas Cassel authored
      [ Upstream commit 30549aab ]
      
      When building stmmac, it is only possible to select CONFIG_DWMAC_GENERIC,
      or any of the glue drivers, when CONFIG_STMMAC_PLATFORM is set.
      The only exception is CONFIG_STMMAC_PCI.
      
      When calling of_mdiobus_register(), it will call our ->reset()
      callback, which is set to stmmac_mdio_reset().
      
      Most of the code in stmmac_mdio_reset() is protected by a
      "#if defined(CONFIG_STMMAC_PLATFORM)", which will evaluate
      to false when CONFIG_STMMAC_PLATFORM=m.
      
      Because of this, the phy reset gpio will only be pulled when
      stmmac is built as built-in, but not when built as modules.
      
      Fix this by using "#if IS_ENABLED()" instead of "#if defined()".
      Signed-off-by: default avatarNiklas Cassel <niklas.cassel@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4f003cb
    • Jakub Kicinski's avatar
      net: sched: gred: pass the right attribute to gred_change_table_def() · 917629e6
      Jakub Kicinski authored
      [ Upstream commit 38b4f18d ]
      
      gred_change_table_def() takes a pointer to TCA_GRED_DPS attribute,
      and expects it will be able to interpret its contents as
      struct tc_gred_sopt.  Pass the correct gred attribute, instead of
      TCA_OPTIONS.
      
      This bug meant the table definition could never be changed after
      Qdisc was initialized (unless whatever TCA_OPTIONS contained both
      passed netlink validation and was a valid struct tc_gred_sopt...).
      
      Old behaviour:
      $ ip link add type dummy
      $ tc qdisc replace dev dummy0 parent root handle 7: \
           gred setup vqs 4 default 0
      $ tc qdisc replace dev dummy0 parent root handle 7: \
           gred setup vqs 4 default 0
      RTNETLINK answers: Invalid argument
      
      Now:
      $ ip link add type dummy
      $ tc qdisc replace dev dummy0 parent root handle 7: \
           gred setup vqs 4 default 0
      $ tc qdisc replace dev dummy0 parent root handle 7: \
           gred setup vqs 4 default 0
      $ tc qdisc replace dev dummy0 parent root handle 7: \
           gred setup vqs 4 default 0
      
      Fixes: f62d6b93 ("[PKT_SCHED]: GRED: Use central VQ change procedure")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      917629e6
    • Eric Dumazet's avatar
      net/mlx5e: fix csum adjustments caused by RXFCS · c5eebcf0
      Eric Dumazet authored
      [ Upstream commit d48051c5 ]
      
      As shown by Dmitris, we need to use csum_block_add() instead of csum_add()
      when adding the FCS contribution to skb csum.
      
      Before 4.18 (more exactly commit 88078d98 "net: pskb_trim_rcsum()
      and CHECKSUM_COMPLETE are friends"), the whole skb csum was thrown away,
      so RXFCS changes were ignored.
      
      Then before commit d55bef50 ("net: fix pskb_trim_rcsum_slow() with
      odd trim offset") both mlx5 and pskb_trim_rcsum_slow() bugs were canceling
      each other.
      
      Now we fixed pskb_trim_rcsum_slow() we need to fix mlx5.
      
      Note that this patch also rewrites mlx5e_get_fcs() to :
      
      - Use skb_header_pointer() instead of reinventing it.
      - Use __get_unaligned_cpu32() to avoid possible non aligned accesses
        as Dmitris pointed out.
      
      Fixes: 902a5459 ("net/mlx5e: When RXFCS is set, add FCS data into checksum calculation")
      Reported-by: default avatarPaweł Staszewski <pstaszewski@itcare.pl>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Eran Ben Elisha <eranbe@mellanox.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Dimitris Michailidis <dmichail@google.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Paweł Staszewski <pstaszewski@itcare.pl>
      Reviewed-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Tested-By: default avatarMaria Pasechnik <mariap@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5eebcf0
    • Stefano Brivio's avatar
      ipv6/ndisc: Preserve IPv6 control buffer if protocol error handlers are called · dc31623a
      Stefano Brivio authored
      [ Upstream commit ee1abcf6 ]
      
      Commit a61bbcf2 ("[NET]: Store skb->timestamp as offset to a base
      timestamp") introduces a neighbour control buffer and zeroes it out in
      ndisc_rcv(), as ndisc_recv_ns() uses it.
      
      Commit f2776ff0 ("[IPV6]: Fix address/interface handling in UDP and
      DCCP, according to the scoping architecture.") introduces the usage of the
      IPv6 control buffer in protocol error handlers (e.g. inet6_iif() in
      present-day __udp6_lib_err()).
      
      Now, with commit b94f1c09 ("ipv6: Use icmpv6_notify() to propagate
      redirect, instead of rt6_redirect()."), we call protocol error handlers
      from ndisc_redirect_rcv(), after the control buffer is already stolen and
      some parts are already zeroed out. This implies that inet6_iif() on this
      path will always return zero.
      
      This gives unexpected results on UDP socket lookup in __udp6_lib_err(), as
      we might actually need to match sockets for a given interface.
      
      Instead of always claiming the control buffer in ndisc_rcv(), do that only
      when needed.
      
      Fixes: b94f1c09 ("ipv6: Use icmpv6_notify() to propagate redirect, instead of rt6_redirect().")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc31623a
    • Hangbin Liu's avatar
      bridge: do not add port to router list when receives query with source 0.0.0.0 · 0f216d94
      Hangbin Liu authored
      [ Upstream commit 5a2de63f ]
      
      Based on RFC 4541, 2.1.1.  IGMP Forwarding Rules
      
        The switch supporting IGMP snooping must maintain a list of
        multicast routers and the ports on which they are attached.  This
        list can be constructed in any combination of the following ways:
      
        a) This list should be built by the snooping switch sending
           Multicast Router Solicitation messages as described in IGMP
           Multicast Router Discovery [MRDISC].  It may also snoop
           Multicast Router Advertisement messages sent by and to other
           nodes.
      
        b) The arrival port for IGMP Queries (sent by multicast routers)
           where the source address is not 0.0.0.0.
      
      We should not add the port to router list when receives query with source
      0.0.0.0.
      Reported-by: default avatarYing Xu <yinxu@redhat.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Acked-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f216d94
  2. 22 Oct, 2018 8 commits
  3. 21 Oct, 2018 3 commits
  4. 20 Oct, 2018 11 commits
  5. 19 Oct, 2018 5 commits