1. 29 Jun, 2022 15 commits
  2. 28 Jun, 2022 11 commits
    • Eric Dumazet's avatar
      net: bonding: fix possible NULL deref in rlb code · ab84db25
      Eric Dumazet authored
      syzbot has two reports involving the same root cause.
      
      bond_alb_initialize() must not set bond->alb_info.rlb_enabled
      if a memory allocation error is detected.
      
      Report 1:
      
      general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
      CPU: 0 PID: 12276 Comm: kworker/u4:10 Not tainted 5.19.0-rc3-syzkaller-00132-g3b89b511 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: netns cleanup_net
      RIP: 0010:rlb_clear_slave+0x10e/0x690 drivers/net/bonding/bond_alb.c:393
      Code: 8e fc 83 fb ff 0f 84 74 02 00 00 e8 cc 2a 8e fc 48 8b 44 24 08 89 dd 48 c1 e5 06 4c 8d 34 28 49 8d 7e 14 48 89 f8 48 c1 e8 03 <42> 0f b6 14 20 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
      RSP: 0018:ffffc90018a8f678 EFLAGS: 00010203
      RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: ffff88803375bb00 RSI: ffffffff84ec4ac4 RDI: 0000000000000014
      RBP: 0000000000000000 R08: 0000000000000005 R09: 00000000ffffffff
      R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
      R13: ffff8880ac889000 R14: 0000000000000000 R15: ffff88815a668c80
      FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00005597077e10b0 CR3: 0000000026668000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
      <TASK>
      bond_alb_deinit_slave+0x43c/0x6b0 drivers/net/bonding/bond_alb.c:1663
      __bond_release_one.cold+0x383/0xd53 drivers/net/bonding/bond_main.c:2370
      bond_slave_netdev_event drivers/net/bonding/bond_main.c:3778 [inline]
      bond_netdev_event+0x993/0xad0 drivers/net/bonding/bond_main.c:3889
      notifier_call_chain+0xb5/0x200 kernel/notifier.c:87
      call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945
      call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
      call_netdevice_notifiers net/core/dev.c:1997 [inline]
      unregister_netdevice_many+0x948/0x18b0 net/core/dev.c:10839
      default_device_exit_batch+0x449/0x590 net/core/dev.c:11333
      ops_exit_list+0x125/0x170 net/core/net_namespace.c:167
      cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594
      process_one_work+0x996/0x1610 kernel/workqueue.c:2289
      worker_thread+0x665/0x1080 kernel/workqueue.c:2436
      kthread+0x2e9/0x3a0 kernel/kthread.c:376
      ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
      </TASK>
      
      Report 2:
      
      general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
      CPU: 1 PID: 5206 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-12108-g58f9d52f #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:rlb_req_update_slave_clients+0x109/0x2f0 drivers/net/bonding/bond_alb.c:502
      Code: 5d 18 8f fc 41 80 3e 00 0f 85 a5 01 00 00 89 d8 48 c1 e0 06 49 03 84 24 68 01 00 00 48 8d 78 30 49 89 c7 48 89 fa 48 c1 ea 03 <80> 3c 2a 00 0f 85 98 01 00 00 4d 39 6f 30 75 83 e8 22 18 8f fc 49
      RSP: 0018:ffffc9000300ee80 EFLAGS: 00010206
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc90016c11000
      RDX: 0000000000000006 RSI: ffffffff84eb6bf3 RDI: 0000000000000030
      RBP: dffffc0000000000 R08: 0000000000000005 R09: 00000000ffffffff
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff888027c80c80
      R13: ffff88807d7ff800 R14: ffffed1004f901bd R15: 0000000000000000
      FS:  00007f6f46c58700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020010000 CR3: 00000000516cc000 CR4: 00000000003506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       alb_fasten_mac_swap+0x886/0xa80 drivers/net/bonding/bond_alb.c:1070
       bond_alb_handle_active_change+0x624/0x1050 drivers/net/bonding/bond_alb.c:1765
       bond_change_active_slave+0xfa1/0x29b0 drivers/net/bonding/bond_main.c:1173
       bond_select_active_slave+0x23f/0xa50 drivers/net/bonding/bond_main.c:1253
       bond_enslave+0x3b34/0x53b0 drivers/net/bonding/bond_main.c:2159
       do_set_master+0x1c8/0x220 net/core/rtnetlink.c:2577
       rtnl_newlink_create net/core/rtnetlink.c:3380 [inline]
       __rtnl_newlink+0x13ac/0x17e0 net/core/rtnetlink.c:3580
       rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3593
       rtnetlink_rcv_msg+0x43a/0xc90 net/core/rtnetlink.c:6089
       netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
       netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
       netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
       netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
       sock_sendmsg_nosec net/socket.c:714 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:734
       ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2546
       __sys_sendmsg net/socket.c:2575 [inline]
       __do_sys_sendmsg net/socket.c:2584 [inline]
       __se_sys_sendmsg net/socket.c:2582 [inline]
       __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
      RIP: 0033:0x7f6f45a89109
      Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f6f46c58168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f6f45b9c030 RCX: 00007f6f45a89109
      RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000006
      RBP: 00007f6f45ae308d R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007ffed99029af R14: 00007f6f46c58300 R15: 0000000000022000
       </TASK>
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Jay Vosburgh <j.vosburgh@gmail.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Link: https://lore.kernel.org/r/20220627102813.126264-1-edumazet@google.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      ab84db25
    • Nicolas Dichtel's avatar
      ipv6: take care of disable_policy when restoring routes · 3b0dc529
      Nicolas Dichtel authored
      When routes corresponding to addresses are restored by
      fixup_permanent_addr(), the dst_nopolicy parameter was not set.
      The typical use case is a user that configures an address on a down
      interface and then put this interface up.
      
      Let's take care of this flag in addrconf_f6i_alloc(), so that every callers
      benefit ont it.
      
      CC: stable@kernel.org
      CC: David Forster <dforster@brocade.com>
      Fixes: df789fe7 ("ipv6: Provide ipv6 version of "disable_policy" sysctl")
      Reported-by: default avatarSiwar Zitouni <siwar.zitouni@6wind.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Link: https://lore.kernel.org/r/20220623120015.32640-1-nicolas.dichtel@6wind.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3b0dc529
    • Oleksij Rempel's avatar
      net: usb: asix: do not force pause frames support · ce95ab77
      Oleksij Rempel authored
      We should respect link partner capabilities and not force flow control
      support on every link. Even more, in current state the MAC driver do not
      advertises pause support so we should not keep flow control enabled at
      all.
      
      Fixes: e532a096 ("net: usb: asix: ax88772: add phylib support")
      Reported-by: default avatarAnton Lundin <glance@acc.umu.se>
      Signed-off-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Tested-by: default avatarAnton Lundin <glance@acc.umu.se>
      Link: https://lore.kernel.org/r/20220624075139.3139300-2-o.rempel@pengutronix.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ce95ab77
    • Oleksij Rempel's avatar
      net: asix: fix "can't send until first packet is send" issue · 805206e6
      Oleksij Rempel authored
      If cable is attached after probe sequence, the usbnet framework would
      not automatically start processing RX packets except at least one
      packet was transmitted.
      
      On systems with any kind of address auto configuration this issue was
      not detected, because some packets are send immediately after link state
      is changed to "running".
      
      With this patch we will notify usbnet about link status change provided by the
      PHYlib.
      
      Fixes: e532a096 ("net: usb: asix: ax88772: add phylib support")
      Reported-by: default avatarAnton Lundin <glance@acc.umu.se>
      Signed-off-by: default avatarOleksij Rempel <o.rempel@pengutronix.de>
      Tested-by: default avatarAnton Lundin <glance@acc.umu.se>
      Link: https://lore.kernel.org/r/20220624075139.3139300-1-o.rempel@pengutronix.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      805206e6
    • Michael Walle's avatar
      MAINTAINERS: nfc: drop Charles Gorand from NXP-NCI · 6b9f1d46
      Michael Walle authored
      Mails to Charles get an auto reply, that he is no longer working at
      Eff'Innov technologies. Drop the entry and mark the driver as orphaned.
      Signed-off-by: default avatarMichael Walle <michael@walle.cc>
      Acked-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      Link: https://lore.kernel.org/r/20220626200039.4062784-1-michael@walle.ccSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6b9f1d46
    • Shreenidhi Shedi's avatar
      octeon_ep: use bitwise AND · 4bbfed91
      Shreenidhi Shedi authored
      This should be bitwise operator not logical.
      
      Fixes: 862cd659 ("octeon_ep: Add driver framework and device initialization")
      Signed-off-by: default avatarShreenidhi Shedi <sshedi@vmware.com>
      Link: https://lore.kernel.org/r/20220626132947.3992423-1-sshedi@vmware.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4bbfed91
    • Jakub Kicinski's avatar
      Merge branch 'notify-user-space-if-any-actions-were-flushed-before-error' · cce13b82
      Jakub Kicinski authored
      Victor Nogueira says:
      
      ====================
      Notify user space if any actions were flushed before error
      
      This patch series fixes the behaviour of actions flush so that the
      kernel always notifies user space whenever it deletes actions during a
      flush operation, even if it didn't flush all the actions. This series
      also introduces tdc tests to verify this new behaviour.
      ====================
      
      Link: https://lore.kernel.org/r/20220623140742.684043-1-victor@mojatatu.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      cce13b82
    • Victor Nogueira's avatar
      selftests: tc-testing: Add testcases to test new flush behaviour · 88153e29
      Victor Nogueira authored
      Add tdc test cases to verify new flush behaviour is correct, which do
      the following:
      
      - Try to flush only one action which is being referenced by a filter
      - Try to flush three actions where the last one (index 3) is being
        referenced by a filter
      Signed-off-by: default avatarVictor Nogueira <victor@mojatatu.com>
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      88153e29
    • Victor Nogueira's avatar
      net/sched: act_api: Notify user space if any actions were flushed before error · 76b39b94
      Victor Nogueira authored
      If during an action flush operation one of the actions is still being
      referenced, the flush operation is aborted and the kernel returns to
      user space with an error. However, if the kernel was able to flush, for
      example, 3 actions and failed on the fourth, the kernel will not notify
      user space that it deleted 3 actions before failing.
      
      This patch fixes that behaviour by notifying user space of how many
      actions were deleted before flush failed and by setting extack with a
      message describing what happened.
      
      Fixes: 55334a5d ("net_sched: act: refuse to remove bound action outside")
      Signed-off-by: default avatarVictor Nogueira <victor@mojatatu.com>
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      76b39b94
    • Tong Zhang's avatar
      epic100: fix use after free on rmmod · 8ee9d82c
      Tong Zhang authored
      epic_close() calls epic_rx() and uses dma buffer, but in epic_remove_one()
      we already freed the dma buffer. To fix this issue, reorder function calls
      like in the .probe function.
      
      BUG: KASAN: use-after-free in epic_rx+0xa6/0x7e0 [epic100]
      Call Trace:
       epic_rx+0xa6/0x7e0 [epic100]
       epic_close+0xec/0x2f0 [epic100]
       unregister_netdev+0x18/0x20
       epic_remove_one+0xaa/0xf0 [epic100]
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarYilun Wu <yiluwu@cs.stonybrook.edu>
      Signed-off-by: default avatarTong Zhang <ztong0001@gmail.com>
      Reviewed-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Link: https://lore.kernel.org/r/20220627043351.25615-1-ztong0001@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8ee9d82c
    • Jakub Kicinski's avatar
      net: tun: stop NAPI when detaching queues · a8fc8cb5
      Jakub Kicinski authored
      While looking at a syzbot report I noticed the NAPI only gets
      disabled before it's deleted. I think that user can detach
      the queue before destroying the device and the NAPI will never
      be stopped.
      
      Fixes: 94317099 ("tun: enable NAPI for TUN/TAP driver")
      Acked-by: default avatarPetar Penkov <ppenkov@aviatrix.com>
      Link: https://lore.kernel.org/r/20220623042105.2274812-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      a8fc8cb5
  3. 27 Jun, 2022 2 commits
    • Xin Long's avatar
      tipc: move bc link creation back to tipc_node_create · cb8092d7
      Xin Long authored
      Shuang Li reported a NULL pointer dereference crash:
      
        [] BUG: kernel NULL pointer dereference, address: 0000000000000068
        [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]
        [] Call Trace:
        []  <IRQ>
        []  tipc_bcast_rcv+0xa2/0x190 [tipc]
        []  tipc_node_bc_rcv+0x8b/0x200 [tipc]
        []  tipc_rcv+0x3af/0x5b0 [tipc]
        []  tipc_udp_recv+0xc7/0x1e0 [tipc]
      
      It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. When it
      creates a node in tipc_node_check_dest(), after inserting the new node
      into hashtable in tipc_node_create(), it creates the bc link. However,
      there is a gap between this insert and bc link creation, a bc packet
      may come in and get the node from the hashtable then try to dereference
      its bc link, which is NULL.
      
      This patch is to fix it by moving the bc link creation before inserting
      into the hashtable.
      
      Note that for a preliminary node becoming "real", the bc link creation
      should also be called before it's rehashed, as we don't create it for
      preliminary nodes.
      
      Fixes: 4cbf8ac2 ("tipc: enable creating a "preliminary" node")
      Reported-by: default avatarShuang Li <shuali@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb8092d7
    • Eric Dumazet's avatar
      tunnels: do not assume mac header is set in skb_tunnel_check_pmtu() · 853a7614
      Eric Dumazet authored
      Recently added debug in commit f9aefd6b ("net: warn if mac header
      was not set") caught a bug in skb_tunnel_check_pmtu(), as shown
      in this syzbot report [1].
      
      In ndo_start_xmit() paths, there is really no need to use skb->mac_header,
      because skb->data is supposed to point at it.
      
      [1] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_mac_header_len include/linux/skbuff.h:2784 [inline]
      WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413
      Modules linked in:
      CPU: 1 PID: 8604 Comm: syz-executor.3 Not tainted 5.19.0-rc2-syzkaller-00443-g8720bd95 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:skb_mac_header_len include/linux/skbuff.h:2784 [inline]
      RIP: 0010:skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413
      Code: 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 84 b9 fe ff ff 4c 89 ff e8 7c 0f d7 f9 e9 ac fe ff ff e8 c2 13 8a f9 <0f> 0b e9 28 fc ff ff e8 b6 13 8a f9 48 8b 54 24 70 48 b8 00 00 00
      RSP: 0018:ffffc90002e4f520 EFLAGS: 00010212
      RAX: 0000000000000324 RBX: ffff88804d5fd500 RCX: ffffc90005b52000
      RDX: 0000000000040000 RSI: ffffffff87f05e3e RDI: 0000000000000003
      RBP: ffffc90002e4f650 R08: 0000000000000003 R09: 000000000000ffff
      R10: 000000000000ffff R11: 0000000000000000 R12: 000000000000ffff
      R13: 0000000000000000 R14: 000000000000ffcd R15: 000000000000001f
      FS: 00007f3babba9700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020000080 CR3: 0000000075319000 CR4: 00000000003506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
      <TASK>
      geneve_xmit_skb drivers/net/geneve.c:927 [inline]
      geneve_xmit+0xcf8/0x35d0 drivers/net/geneve.c:1107
      __netdev_start_xmit include/linux/netdevice.h:4805 [inline]
      netdev_start_xmit include/linux/netdevice.h:4819 [inline]
      __dev_direct_xmit+0x500/0x730 net/core/dev.c:4309
      dev_direct_xmit include/linux/netdevice.h:3007 [inline]
      packet_direct_xmit+0x1b8/0x2c0 net/packet/af_packet.c:282
      packet_snd net/packet/af_packet.c:3073 [inline]
      packet_sendmsg+0x21f4/0x55d0 net/packet/af_packet.c:3104
      sock_sendmsg_nosec net/socket.c:714 [inline]
      sock_sendmsg+0xcf/0x120 net/socket.c:734
      ____sys_sendmsg+0x6eb/0x810 net/socket.c:2489
      ___sys_sendmsg+0xf3/0x170 net/socket.c:2543
      __sys_sendmsg net/socket.c:2572 [inline]
      __do_sys_sendmsg net/socket.c:2581 [inline]
      __se_sys_sendmsg net/socket.c:2579 [inline]
      __x64_sys_sendmsg+0x132/0x220 net/socket.c:2579
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x46/0xb0
      RIP: 0033:0x7f3baaa89109
      Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f3babba9168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f3baab9bf60 RCX: 00007f3baaa89109
      RDX: 0000000000000000 RSI: 0000000020000a00 RDI: 0000000000000003
      RBP: 00007f3baaae305d R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007ffe74f2543f R14: 00007f3babba9300 R15: 0000000000022000
      </TASK>
      
      Fixes: 4cb47a86 ("tunnels: PMTU discovery support for directly bridged IP packets")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Stefano Brivio <sbrivio@redhat.com>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      853a7614
  4. 24 Jun, 2022 12 commits