1. 08 Jan, 2019 4 commits
  2. 07 Jan, 2019 14 commits
  3. 06 Jan, 2019 3 commits
  4. 05 Jan, 2019 5 commits
    • David Ahern's avatar
      ipv6: Take rcu_read_lock in __inet6_bind for mapped addresses · d4a7e9bb
      David Ahern authored
      I realized the last patch calls dev_get_by_index_rcu in a branch not
      holding the rcu lock. Add the calls to rcu_read_lock and rcu_read_unlock.
      
      Fixes: ec90ad33 ("ipv6: Consider sk_bound_dev_if when binding a socket to a v4 mapped address")
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4a7e9bb
    • Alexei Starovoitov's avatar
      Merge branch 'udpv6_sendmsg-addr_any-fix' · 466f89e9
      Alexei Starovoitov authored
      Andrey Ignatov says:
      
      ====================
      The patch set fixes BSD'ism in sys_sendmsg to rewrite unspecified
      destination IPv6 for unconnected UDP sockets in sys_sendmsg with [::1] in
      case when either CONFIG_CGROUP_BPF is enabled or when sys_sendmsg BPF hook
      sets destination IPv6 to [::].
      
      Patch 1 is the fix and provides more details.
      Patch 2 adds two test cases to verify the fix.
      
      v1->v2:
      * Fix compile error in patch 1.
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      466f89e9
    • Andrey Ignatov's avatar
      selftests/bpf: Test [::] -> [::1] rewrite in sys_sendmsg in test_sock_addr · 976b4f3a
      Andrey Ignatov authored
      Test that sys_sendmsg BPF hook doesn't break sys_sendmsg behaviour to
      rewrite destination IPv6 = [::] with [::1] (BSD'ism).
      
      Two test cases are added:
      
      1) User passes dst IPv6 = [::] and BPF_CGROUP_UDP6_SENDMSG program
         doesn't touch it.
      
      2) User passes dst IPv6 != [::], but BPF_CGROUP_UDP6_SENDMSG program
         rewrites it with [::].
      
      In both cases [::1] is used by sys_sendmsg code eventually and datagram
      is sent successfully for unconnected UDP socket.
      
      Example of relevant output:
        Test case: sendmsg6: set dst IP = [::] (BSD'ism) .. [PASS]
        Test case: sendmsg6: preserve dst IP = [::] (BSD'ism) .. [PASS]
      Signed-off-by: default avatarAndrey Ignatov <rdna@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      976b4f3a
    • Andrey Ignatov's avatar
      bpf: Fix [::] -> [::1] rewrite in sys_sendmsg · e8e36984
      Andrey Ignatov authored
      sys_sendmsg has supported unspecified destination IPv6 (wildcard) for
      unconnected UDP sockets since 876c7f41. When [::] is passed by user as
      destination, sys_sendmsg rewrites it with [::1] to be consistent with
      BSD (see "BSD'ism" comment in the code).
      
      This didn't work when cgroup-bpf was enabled though since the rewrite
      [::] -> [::1] happened before passing control to cgroup-bpf block where
      fl6.daddr was updated with passed by user sockaddr_in6.sin6_addr (that
      might or might not be changed by BPF program). That way if user passed
      [::] as dst IPv6 it was first rewritten with [::1] by original code from
      876c7f41, but then rewritten back with [::] by cgroup-bpf block.
      
      It happened even when BPF_CGROUP_UDP6_SENDMSG program was not present
      (CONFIG_CGROUP_BPF=y was enough).
      
      The fix is to apply BSD'ism after cgroup-bpf block so that [::] is
      replaced with [::1] no matter where it came from: passed by user to
      sys_sendmsg or set by BPF_CGROUP_UDP6_SENDMSG program.
      
      Fixes: 1cedee13 ("bpf: Hooks for sys_sendmsg")
      Reported-by: default avatarNitin Rawat <nitin.rawat@intel.com>
      Signed-off-by: default avatarAndrey Ignatov <rdna@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      e8e36984
    • David Ahern's avatar
      ipv6: Consider sk_bound_dev_if when binding a socket to a v4 mapped address · ec90ad33
      David Ahern authored
      Similar to c5ee0663 ("ipv6: Consider sk_bound_dev_if when binding a
      socket to an address"), binding a socket to v4 mapped addresses needs to
      consider if the socket is bound to a device.
      
      This problem also exists from the beginning of git history.
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec90ad33
  5. 04 Jan, 2019 14 commits
    • Jeff Kirsher's avatar
      ixgbe: fix Kconfig when driver is not a module · ae84e4a8
      Jeff Kirsher authored
      The new ability added to the driver to use mii_bus to handle MII related
      ioctls is causing compile issues when the driver is compiled into the
      kernel (i.e. not a module).
      
      The problem was in selecting MDIO_DEVICE instead of the preferred PHYLIB
      Kconfig option.  The reason being that MDIO_DEVICE had a dependency on
      PHYLIB and would be compiled as a module when PHYLIB was a module, no
      matter whether ixgbe was compiled into the kernel.
      
      CC: Dave Jones <davej@codemonkey.org.uk>
      CC: Steve Douthit <stephend@silicom-usa.com>
      CC: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Reviewed-by: default avatarStephen Douthit <stephend@silicom-usa.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae84e4a8
    • Eric Dumazet's avatar
      ipv6: make icmp6_send() robust against null skb->dev · 8d933670
      Eric Dumazet authored
      syzbot was able to crash one host with the following stack trace :
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 0 PID: 8625 Comm: syz-executor4 Not tainted 4.20.0+ #8
      RIP: 0010:dev_net include/linux/netdevice.h:2169 [inline]
      RIP: 0010:icmp6_send+0x116/0x2d30 net/ipv6/icmp.c:426
       icmpv6_send
       smack_socket_sock_rcv_skb
       security_sock_rcv_skb
       sk_filter_trim_cap
       __sk_receive_skb
       dccp_v6_do_rcv
       release_sock
      
      This is because a RX packet found socket owned by user and
      was stored into socket backlog. Before leaving RCU protected section,
      skb->dev was cleared in __sk_receive_skb(). When socket backlog
      was finally handled at release_sock() time, skb was fed to
      smack_socket_sock_rcv_skb() then icmp6_send()
      
      We could fix the bug in smack_socket_sock_rcv_skb(), or simply
      make icmp6_send() more robust against such possibility.
      
      In the future we might provide to icmp6_send() the net pointer
      instead of infering it.
      
      Fixes: d66a8acb ("Smack: Inform peer that IPv6 traffic has been blocked")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Piotr Sawicki <p.sawicki2@partner.samsung.com>
      Cc: Casey Schaufler <casey@schaufler-ca.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d933670
    • Peter Oskolkov's avatar
      selftests: net: fix/improve ip_defrag selftest · 3271a482
      Peter Oskolkov authored
      Commit ade44640 ("net: ipv4: do not handle duplicate fragments as
      overlapping") changed IPv4 defragmentation so that duplicate fragments,
      as well as _some_ fragments completely covered by previously delivered
      fragments, do not lead to the whole frag queue being discarded. This
      makes the existing ip_defrag selftest flaky.
      
      This patch
      * makes sure that negative IPv4 defrag tests generate truly overlapping
        fragments that trigger defrag queue drops;
      * tests that duplicate IPv4 fragments do not trigger defrag queue drops;
      * makes a couple of minor tweaks to the test aimed at increasing its code
        coverage and reduce flakiness.
      Signed-off-by: default avatarPeter Oskolkov <posk@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3271a482
    • Daniele Palmas's avatar
      qmi_wwan: add MTU default to qmap network interface · f87118d5
      Daniele Palmas authored
      This patch adds MTU default value to qmap network interface in
      order to avoid "RTNETLINK answers: No buffer space available"
      error when setting an ipv6 address.
      Signed-off-by: default avatarDaniele Palmas <dnlplm@gmail.com>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f87118d5
    • David S. Miller's avatar
      Merge branch 'hns-fixes' · 75e7fb0a
      David S. Miller authored
      Huazhong Tan says:
      
      ====================
      net: hns: Bugfixes for HNS driver
      
      This patchset includes bugfixes for the HNS ethernet controller driver.
      
      Every patch is independent.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      75e7fb0a
    • Yonglong Liu's avatar
      net: hns: Fix use after free identified by SLUB debug · bb989501
      Yonglong Liu authored
      When enable SLUB debug, than remove hns_enet_drv module, SLUB debug will
      identify a use after free bug:
      
      [134.189505] Unable to handle kernel paging request at virtual address
      		006b6b6b6b6b6b6b
      [134.197553] Mem abort info:
      [134.200381]   ESR = 0x96000004
      [134.203487]   Exception class = DABT (current EL), IL = 32 bits
      [134.209497]   SET = 0, FnV = 0
      [134.212596]   EA = 0, S1PTW = 0
      [134.215777] Data abort info:
      [134.218701]   ISV = 0, ISS = 0x00000004
      [134.222596]   CM = 0, WnR = 0
      [134.225606] [006b6b6b6b6b6b6b] address between user and kernel address ranges
      [134.232851] Internal error: Oops: 96000004 [#1] SMP
      [134.237798] CPU: 21 PID: 27834 Comm: rmmod Kdump: loaded Tainted: G
      		OE     4.19.5-1.2.34.aarch64 #1
      [134.247856] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.58 10/24/2018
      [134.255181] pstate: 20000005 (nzCv daif -PAN -UAO)
      [134.260044] pc : hns_ae_put_handle+0x38/0x60
      [134.264372] lr : hns_ae_put_handle+0x24/0x60
      [134.268700] sp : ffff00001be93c50
      [134.272054] x29: ffff00001be93c50 x28: ffff802faaec8040
      [134.277442] x27: 0000000000000000 x26: 0000000000000000
      [134.282830] x25: 0000000056000000 x24: 0000000000000015
      [134.288284] x23: ffff0000096fe098 x22: ffff000001050070
      [134.293671] x21: ffff801fb3c044a0 x20: ffff80afb75ec098
      [134.303287] x19: ffff80afb75ec098 x18: 0000000000000000
      [134.312945] x17: 0000000000000000 x16: 0000000000000000
      [134.322517] x15: 0000000000000002 x14: 0000000000000000
      [134.332030] x13: dead000000000100 x12: ffff7e02bea3c988
      [134.341487] x11: ffff80affbee9e68 x10: 0000000000000000
      [134.351033] x9 : 6fffff8000008101 x8 : 0000000000000000
      [134.360569] x7 : dead000000000100 x6 : ffff000009579748
      [134.370059] x5 : 0000000000210d00 x4 : 0000000000000000
      [134.379550] x3 : 0000000000000001 x2 : 0000000000000000
      [134.388813] x1 : 6b6b6b6b6b6b6b6b x0 : 0000000000000000
      [134.397993] Process rmmod (pid: 27834, stack limit = 0x00000000d474b7fd)
      [134.408498] Call trace:
      [134.414611]  hns_ae_put_handle+0x38/0x60
      [134.422208]  hnae_put_handle+0xd4/0x108
      [134.429563]  hns_nic_dev_remove+0x60/0xc0 [hns_enet_drv]
      [134.438342]  platform_drv_remove+0x2c/0x70
      [134.445958]  device_release_driver_internal+0x174/0x208
      [134.454810]  driver_detach+0x70/0xd8
      [134.461913]  bus_remove_driver+0x64/0xe8
      [134.469396]  driver_unregister+0x34/0x60
      [134.476822]  platform_driver_unregister+0x20/0x30
      [134.485130]  hns_nic_dev_driver_exit+0x14/0x6e4 [hns_enet_drv]
      [134.494634]  __arm64_sys_delete_module+0x238/0x290
      
      struct hnae_handle is a member of struct hnae_vf_cb, so when vf_cb is
      freed, than use hnae_handle will cause use after free panic.
      
      This patch frees vf_cb after hnae_handle used.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb989501
    • Yonglong Liu's avatar
      net: hns: Fix WARNING when hns modules installed · c77804be
      Yonglong Liu authored
      Commit 308c6caf ("net: hns: All ports can not work when insmod hns ko
      after rmmod.") add phy_stop in hns_nic_init_phy(), In the branch of "net",
      this method is effective, but in the branch of "net-next", it will cause
      a WARNING when hns modules loaded, reference to commit 2b3e88ea ("net:
      phy: improve phy state checking"):
      
      [10.092168] ------------[ cut here ]------------
      [10.092171] called from state READY
      [10.092189] WARNING: CPU: 4 PID: 1 at ../drivers/net/phy/phy.c:854
                      phy_stop+0x90/0xb0
      [10.092192] Modules linked in:
      [10.092197] CPU: 4 PID:1 Comm:swapper/0 Not tainted 4.20.0-rc7-next-20181220 #1
      [10.092200] Hardware name: Huawei TaiShan 2280 /D05, BIOS Hisilicon D05 UEFI
                      16.12 Release 05/15/2017
      [10.092202] pstate: 60000005 (nZCv daif -PAN -UAO)
      [10.092205] pc : phy_stop+0x90/0xb0
      [10.092208] lr : phy_stop+0x90/0xb0
      [10.092209] sp : ffff00001159ba90
      [10.092212] x29: ffff00001159ba90 x28: 0000000000000007
      [10.092215] x27: ffff000011180068 x26: ffff0000110a5620
      [10.092218] x25: ffff0000113b6000 x24: ffff842f96dac000
      [10.092221] x23: 0000000000000000 x22: 0000000000000000
      [10.092223] x21: ffff841fb8425e18 x20: ffff801fb3a56438
      [10.092226] x19: ffff801fb3a56000 x18: ffffffffffffffff
      [10.092228] x17: 0000000000000000 x16: 0000000000000000
      [10.092231] x15: ffff00001122d6c8 x14: ffff00009159b7b7
      [10.092234] x13: ffff00001159b7c5 x12: ffff000011245000
      [10.092236] x11: 0000000005f5e0ff x10: ffff00001159b750
      [10.092239] x9 : 00000000ffffffd0 x8 : 0000000000000465
      [10.092242] x7 : ffff0000112457f8 x6 : ffff0000113bd7ce
      [10.092245] x5 : 0000000000000000 x4 : 0000000000000000
      [10.092247] x3 : 00000000ffffffff x2 : ffff000011245828
      [10.092250] x1 : 4b5860bd05871300 x0 : 0000000000000000
      [10.092253] Call trace:
      [10.092255]  phy_stop+0x90/0xb0
      [10.092260]  hns_nic_init_phy+0xf8/0x110
      [10.092262]  hns_nic_try_get_ae+0x4c/0x3b0
      [10.092264]  hns_nic_dev_probe+0x1fc/0x480
      [10.092268]  platform_drv_probe+0x50/0xa0
      [10.092271]  really_probe+0x1f4/0x298
      [10.092273]  driver_probe_device+0x58/0x108
      [10.092275]  __driver_attach+0xdc/0xe0
      [10.092278]  bus_for_each_dev+0x74/0xc8
      [10.092280]  driver_attach+0x20/0x28
      [10.092283]  bus_add_driver+0x1b8/0x228
      [10.092285]  driver_register+0x60/0x110
      [10.092288]  __platform_driver_register+0x40/0x48
      [10.092292]  hns_nic_dev_driver_init+0x18/0x20
      [10.092296]  do_one_initcall+0x5c/0x180
      [10.092299]  kernel_init_freeable+0x198/0x240
      [10.092303]  kernel_init+0x10/0x108
      [10.092306]  ret_from_fork+0x10/0x18
      [10.092308] ---[ end trace 1396dd0278e397eb ]---
      
      This WARNING occurred because of calling phy_stop before phy_start.
      
      The root cause of the problem in commit '308c6caf' is:
      
      Reference to hns_nic_init_phy, the flag phydev->supported is changed after
      phy_connect_direct. The flag phydev->supported is 0x6ff when hns modules is
      loaded, so will not change Fiber Port power(Reference to marvell.c), which
      is power on at default.
      Then the flag phydev->supported is changed to 0x6f, so Fiber Port power is
      off when removing hns modules.
      When hns modules installed again, the flag phydev->supported is default
      value 0x6ff, so will not change Fiber Port power(now is off), causing mac
      link not up problem.
      
      So the solution is change phy flags before phy_connect_direct.
      
      Fixes: 308c6caf ("net: hns: All ports can not work when insmod hns ko after rmmod.")
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c77804be
    • Linus Walleij's avatar
      net: dsa: mt7530: Drop unused GPIO include · cff1e01f
      Linus Walleij authored
      This driver uses GPIO descriptors only, <linux/of_gpio.h>
      is not used so drop the include.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cff1e01f
    • David S. Miller's avatar
      Merge branch 'GUE-error-recursion' · 0c06a091
      David S. Miller authored
      Stefano Brivio says:
      
      ====================
      Fix two further potential unbounded recursions in GUE error handlers
      
      Patch 1/2 takes care of preventing the issue fixed by commit 11789039
      ("fou: Prevent unbounded recursion in GUE error handler") also with
      UDP-Lite payloads -- I just realised this might happen from a syzbot
      report.
      
      Patch 2/2 fixes the issue for both UDP and UDP-Lite on IPv6, which I also
      forgot to deal with in that same commit.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c06a091
    • Stefano Brivio's avatar
      fou6: Prevent unbounded recursion in GUE error handler · 44039e00
      Stefano Brivio authored
      I forgot to deal with IPv6 in commit 11789039 ("fou: Prevent unbounded
      recursion in GUE error handler").
      
      Now syzbot reported what might be the same type of issue, caused by
      gue6_err(), that is, handling exceptions for direct UDP encapsulation in
      GUE (UDP-in-UDP) leads to unbounded recursion in the GUE exception
      handler.
      
      As it probably doesn't make sense to set up GUE this way, and it's
      currently not even possible to configure this, skip exception handling for
      UDP (or UDP-Lite) packets encapsulated in UDP (or UDP-Lite) packets with
      GUE on IPv6.
      
      Reported-by: syzbot+4ad25edc7a33e4ab91e0@syzkaller.appspotmail.com
      Reported-by: default avatarWillem de Bruijn <willemdebruijn.kernel@gmail.com>
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Fixes: b8a51b38 ("fou, fou6: ICMP error handlers for FoU and GUE")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      44039e00
    • Stefano Brivio's avatar
      fou: Prevent unbounded recursion in GUE error handler also with UDP-Lite · bc6e019b
      Stefano Brivio authored
      In commit 11789039 ("fou: Prevent unbounded recursion in GUE error
      handler"), I didn't take care of the case where UDP-Lite is encapsulated
      into UDP or UDP-Lite with GUE. From a syzbot report about a possibly
      similar issue with GUE on IPv6, I just realised the same thing might
      happen with a UDP-Lite inner payload.
      
      Also skip exception handling for inner UDP-Lite protocol.
      
      Fixes: 11789039 ("fou: Prevent unbounded recursion in GUE error handler")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc6e019b
    • Yi-Hung Wei's avatar
      openvswitch: Fix IPv6 later frags parsing · 41e4e2cd
      Yi-Hung Wei authored
      The previous commit fa642f08
      ("openvswitch: Derive IP protocol number for IPv6 later frags")
      introduces IP protocol number parsing for IPv6 later frags that can mess
      up the network header length calculation logic, i.e. nh_len < 0.
      However, the network header length calculation is mainly for deriving
      the transport layer header in the key extraction process which the later
      fragment does not apply.
      
      Therefore, this commit skips the network header length calculation to
      fix the issue.
      Reported-by: default avatarChris Mi <chrism@mellanox.com>
      Reported-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Fixes: fa642f08 ("openvswitch: Derive IP protocol number for IPv6 later frags")
      Signed-off-by: default avatarYi-Hung Wei <yihung.wei@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41e4e2cd
    • Claudiu Beznea's avatar
      net: macb: remove unnecessary code · ba3e1847
      Claudiu Beznea authored
      Commit 653e92a9 ("net: macb: add support for padding and fcs
      computation") introduced a bug fixed by commit 899ecaed ("net:
      ethernet: cadence: fix socket buffer corruption problem"). Code removed
      in this patch is not reachable at all so remove it.
      
      Fixes: 653e92a9 ("net: macb: add support for padding and fcs computation")
      Cc: Tristram Ha <Tristram.Ha@microchip.com>
      Signed-off-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba3e1847
    • Linus Walleij's avatar
      net: dsa: microchip: Drop unused GPIO includes · a09b42ba
      Linus Walleij authored
      This driver does not use the old GPIO includes so drop
      them.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a09b42ba