1. 05 Oct, 2018 6 commits
  2. 04 Oct, 2018 6 commits
    • Ido Schimmel's avatar
      team: Forbid enslaving team device to itself · 471b83bd
      Ido Schimmel authored
      team's ndo_add_slave() acquires 'team->lock' and later tries to open the
      newly enslaved device via dev_open(). This emits a 'NETDEV_UP' event
      that causes the VLAN driver to add VLAN 0 on the team device. team's
      ndo_vlan_rx_add_vid() will also try to acquire 'team->lock' and
      deadlock.
      
      Fix this by checking early at the enslavement function that a team
      device is not being enslaved to itself.
      
      A similar check was added to the bond driver in commit 09a89c21
      ("bonding: disallow enslaving a bond to itself").
      
      WARNING: possible recursive locking detected
      4.18.0-rc7+ #176 Not tainted
      --------------------------------------------
      syz-executor4/6391 is trying to acquire lock:
      (____ptrval____) (&team->lock){+.+.}, at: team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
      
      but task is already holding lock:
      (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&team->lock);
        lock(&team->lock);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      2 locks held by syz-executor4/6391:
       #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline]
       #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4662
       #1: (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
      
      stack backtrace:
      CPU: 1 PID: 6391 Comm: syz-executor4 Not tainted 4.18.0-rc7+ #176
      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+0x1c9/0x2b4 lib/dump_stack.c:113
       print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
       check_deadlock kernel/locking/lockdep.c:1809 [inline]
       validate_chain kernel/locking/lockdep.c:2405 [inline]
       __lock_acquire.cold.64+0x1fb/0x486 kernel/locking/lockdep.c:3435
       lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
       __mutex_lock_common kernel/locking/mutex.c:757 [inline]
       __mutex_lock+0x176/0x1820 kernel/locking/mutex.c:894
       mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:909
       team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
       vlan_add_rx_filter_info+0x14a/0x1d0 net/8021q/vlan_core.c:210
       __vlan_vid_add net/8021q/vlan_core.c:278 [inline]
       vlan_vid_add+0x63e/0x9d0 net/8021q/vlan_core.c:308
       vlan_device_event.cold.12+0x2a/0x2f net/8021q/vlan.c:381
       notifier_call_chain+0x180/0x390 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
       call_netdevice_notifiers net/core/dev.c:1753 [inline]
       dev_open+0x173/0x1b0 net/core/dev.c:1433
       team_port_add drivers/net/team/team.c:1219 [inline]
       team_add_slave+0xa8b/0x1c30 drivers/net/team/team.c:1948
       do_set_master+0x1c9/0x220 net/core/rtnetlink.c:2248
       do_setlink+0xba4/0x3e10 net/core/rtnetlink.c:2382
       rtnl_setlink+0x2a9/0x400 net/core/rtnetlink.c:2636
       rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665
       netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2455
       rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683
       netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
       netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
       netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1908
       sock_sendmsg_nosec net/socket.c:642 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:652
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2126
       __sys_sendmsg+0x11d/0x290 net/socket.c:2164
       __do_sys_sendmsg net/socket.c:2173 [inline]
       __se_sys_sendmsg net/socket.c:2171 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x456b29
      Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f9706bf8c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f9706bf96d4 RCX: 0000000000456b29
      RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004
      RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000004d3548 R14: 00000000004c8227 R15: 0000000000000000
      
      Fixes: 87002b03 ("net: introduce vlan_vid_[add/del] and use them instead of direct [add/kill]_vid ndo calls")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-and-tested-by: syzbot+bd051aba086537515cdb@syzkaller.appspotmail.com
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      471b83bd
    • Yu Zhao's avatar
      net/usb: cancel pending work when unbinding smsc75xx · f7b2a56e
      Yu Zhao authored
      Cancel pending work before freeing smsc75xx private data structure
      during binding. This fixes the following crash in the driver:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      IP: mutex_lock+0x2b/0x3f
      <snipped>
      Workqueue: events smsc75xx_deferred_multicast_write [smsc75xx]
      task: ffff8caa83e85700 task.stack: ffff948b80518000
      RIP: 0010:mutex_lock+0x2b/0x3f
      <snipped>
      Call Trace:
       smsc75xx_deferred_multicast_write+0x40/0x1af [smsc75xx]
       process_one_work+0x18d/0x2fc
       worker_thread+0x1a2/0x269
       ? pr_cont_work+0x58/0x58
       kthread+0xfa/0x10a
       ? pr_cont_work+0x58/0x58
       ? rcu_read_unlock_sched_notrace+0x48/0x48
       ret_from_fork+0x22/0x40
      Signed-off-by: default avatarYu Zhao <yuzhao@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7b2a56e
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2018-10-04' of... · 9e15ff7b
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2018-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      Just three small fixes:
       * fix use-after-free in regulatory code
       * fix rx-mgmt key flag in AP mode (mac80211)
       * fix wireless extensions compat code memory leak
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e15ff7b
    • David S. Miller's avatar
      Merge branch 'mlxsw-fixes' · b576eddb
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Couple of fixes
      
      First patch works around an hardware issue in Spectrum-2 where a field
      indicating the event type is always set to the same value. Since there
      are only two event types and they are reported using different queues,
      we can use the queue number to derive the event type.
      
      Second patch prevents a router interface (RIF) leakage when a VLAN
      device is deleted from on top a bridge device.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b576eddb
    • Ido Schimmel's avatar
      mlxsw: spectrum: Delete RIF when VLAN device is removed · c360867e
      Ido Schimmel authored
      In commit 602b74ed ("mlxsw: spectrum_switchdev: Do not leak RIFs
      when removing bridge") I handled the case where RIFs created for VLAN
      devices were not properly cleaned up when their real device (a bridge)
      was removed.
      
      However, I forgot to handle the case of the VLAN device itself being
      removed. Do so now when the VLAN device is being unlinked from its real
      device.
      
      Fixes: 99f44bb3 ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reported-by: default avatarArtem Shvorin <art@qrator.net>
      Tested-by: default avatarArtem Shvorin <art@qrator.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c360867e
    • Nir Dotan's avatar
      mlxsw: pci: Derive event type from event queue number · f3c84a8e
      Nir Dotan authored
      Due to a hardware issue in Spectrum-2, the field event_type of the event
      queue element (EQE) has become reserved. It was used to distinguish between
      command interface completion events and completion events.
      
      Use queue number to determine event type, as command interface completion
      events are always received on EQ0 and mlxsw driver maps completion events
      to EQ1.
      
      Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
      Signed-off-by: default avatarNir Dotan <nird@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f3c84a8e
  3. 03 Oct, 2018 16 commits
  4. 02 Oct, 2018 12 commits
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2018-10-01' of... · 11bde899
      David S. Miller authored
      Merge tag 'wireless-drivers-for-davem-2018-10-01' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 4.19
      
      First, and also hopefully the last, set of fixes for 4.19. All small
      but still important fixes
      
      mt76x0
      
      * fix a bug when a virtual interface is removed multiple times
      
      b43
      
      * fix DMA error related regression with proprietary firmware
      
      iwlwifi
      
      * fix an oops which was a regression in v4.19-rc1
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      11bde899
    • Eric Dumazet's avatar
      rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096 · 0e1d6eca
      Eric Dumazet authored
      We have an impressive number of syzkaller bugs that are linked
      to the fact that syzbot was able to create a networking device
      with millions of TX (or RX) queues.
      
      Let's limit the number of RX/TX queues to 4096, this really should
      cover all known cases.
      
      A separate patch will add various cond_resched() in the loops
      handling sysfs entries at device creation and dismantle.
      
      Tested:
      
      lpaa6:~# ip link add gre-4097 numtxqueues 4097 numrxqueues 4097 type ip6gretap
      RTNETLINK answers: Invalid argument
      
      lpaa6:~# time ip link add gre-4096 numtxqueues 4096 numrxqueues 4096 type ip6gretap
      
      real	0m0.180s
      user	0m0.000s
      sys	0m0.107s
      
      Fixes: 76ff5cc9 ("rtnl: allow to specify number of rx and tx queues on device creation")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0e1d6eca
    • Mahesh Bandewar's avatar
      bonding: fix warning message · 0f3b914c
      Mahesh Bandewar authored
      RX queue config for bonding master could be different from its slave
      device(s). With the commit 6a9e461f ("bonding: pass link-local
      packets to bonding master also."), the packet is reinjected into stack
      with skb->dev as bonding master. This potentially triggers the
      message:
      
         "bondX received packet on queue Y, but number of RX queues is Z"
      
      whenever the queue that packet is received on is higher than the
      numrxqueues on bonding master (Y > Z).
      
      Fixes: 6a9e461f ("bonding: pass link-local packets to bonding master also.")
      Reported-by: default avatarJohn Sperbeck <jsperbeck@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarMahesh Bandewar <maheshb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f3b914c
    • Eric Dumazet's avatar
      inet: make sure to grab rcu_read_lock before using ireq->ireq_opt · 2ab2ddd3
      Eric Dumazet authored
      Timer handlers do not imply rcu_read_lock(), so my recent fix
      triggered a LOCKDEP warning when SYNACK is retransmit.
      
      Lets add rcu_read_lock()/rcu_read_unlock() pairs around ireq->ireq_opt
      usages instead of guessing what is done by callers, since it is
      not worth the pain.
      
      Get rid of ireq_opt_deref() helper since it hides the logic
      without real benefit, since it is now a standard rcu_dereference().
      
      Fixes: 1ad98e9d ("tcp/dccp: fix lockdep issue when SYN is backlogged")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ab2ddd3
    • Jakub Kicinski's avatar
      nfp: avoid soft lockups under control message storm · ff58e2df
      Jakub Kicinski authored
      When FW floods the driver with control messages try to exit the cmsg
      processing loop every now and then to avoid soft lockups.  Cmsg
      processing is generally very lightweight so 512 seems like a reasonable
      budget, which should not be exceeded under normal conditions.
      
      Fixes: 77ece8d5 ("nfp: add control vNIC datapath")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Tested-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff58e2df
    • Maciej W. Rozycki's avatar
      declance: Fix continuation with the adapter identification message · fe3a83af
      Maciej W. Rozycki authored
      Fix a commit 4bcc595c ("printk: reinstate KERN_CONT for printing
      continuation lines") regression with the `declance' driver, which caused
      the adapter identification message to be split between two lines, e.g.:
      
      declance.c: v0.011 by Linux MIPS DECstation task force
      tc6: PMAD-AA
      , addr = 08:00:2b:1b:2a:6a, irq = 14
      tc6: registered as eth0.
      
      Address that properly, by printing identification with a single call,
      making the messages now look like:
      
      declance.c: v0.011 by Linux MIPS DECstation task force
      tc6: PMAD-AA, addr = 08:00:2b:1b:2a:6a, irq = 14
      tc6: registered as eth0.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Fixes: 4bcc595c ("printk: reinstate KERN_CONT for printing continuation lines")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe3a83af
    • Rickard x Andersson's avatar
      net: fec: fix rare tx timeout · 657ade07
      Rickard x Andersson authored
      During certain heavy network loads TX could time out
      with TX ring dump.
      TX is sometimes never restarted after reaching
      "tx_stop_threshold" because function "fec_enet_tx_queue"
      only tests the first queue.
      
      In addition the TX timeout callback function failed to
      recover because it also operated only on the first queue.
      Signed-off-by: default avatarRickard x Andersson <rickaran@axis.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      657ade07
    • Greg Kroah-Hartman's avatar
      Merge tag 'fbdev-v4.19-rc7' of https://github.com/bzolnier/linux · 1d2ba7fe
      Greg Kroah-Hartman authored
      Bartlomiej writes:
        "fbdev fixes for v4.19-rc7:
      
         - fix OMAPFB_MEMORY_READ ioctl to not leak kernel memory in omapfb driver
           (Tomi Valkeinen)
      
         - add missing prepare/unprepare clock operations in pxa168fb driver
           (Lubomir Rintel)
      
         - add nobgrt option in efifb driver to disable ACPI BGRT logo restore
           (Hans de Goede)
      
         - fix spelling mistake in fall-through annotation in stifb driver
           (Gustavo A. R. Silva)
      
         - fix URL for uvesafb repository in the documentation (Adam Jackson)"
      
      * tag 'fbdev-v4.19-rc7' of https://github.com/bzolnier/linux:
        video/fbdev/stifb: Fix spelling mistake in fall-through annotation
        uvesafb: Fix URLs in the documentation
        efifb: BGRT: Add nobgrt option
        fbdev/omapfb: fix omapfb_memory_read infoleak
        pxa168fb: prepare the clock
      1d2ba7fe
    • Greg Kroah-Hartman's avatar
      Merge tag 'mmc-v4.19-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · 5e0b19ac
      Greg Kroah-Hartman authored
      Ulf writes:
        "MMC core:
          - Fixup conversion of debounce time to/from ms/us
      
         MMC host:
          - sdhi: Fixup whitelisting for Gen3 types"
      
      * tag 'mmc-v4.19-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
        mmc: slot-gpio: Fix debounce time to use miliseconds again
        mmc: core: Fix debounce time to use microseconds
        mmc: sdhi: sys_dmac: check for all Gen3 types when whitelisting
      5e0b19ac
    • Heiner Kallweit's avatar
      r8169: fix network stalls due to missing bit TXCFG_AUTO_FIFO · ad5f97fa
      Heiner Kallweit authored
      Some of the chip-specific hw_start functions set bit TXCFG_AUTO_FIFO
      in register TxConfig. The original patch changed the order of some
      calls resulting in these changes being overwritten by
      rtl_set_tx_config_registers() in rtl_hw_start(). This eventually
      resulted in network stalls especially under high load.
      
      Analyzing the chip-specific hw_start functions all chip version from
      34, with the exception of version 39, need this bit set.
      This patch moves setting this bit to rtl_set_tx_config_registers().
      
      Fixes: 4fd48c4a ("r8169: move common initializations to tp->hw_start")
      Reported-by: default avatarOrtwin Glück <odi@odi.ch>
      Reported-by: default avatarDavid Arendt <admin@prnet.org>
      Root-caused-by: default avatarMaciej S. Szmigiero <mail@maciej.szmigiero.name>
      Tested-by: default avatarTony Atkinson <tatkinson@linux.com>
      Tested-by: default avatarDavid Arendt <admin@prnet.org>
      Tested-by: default avatarOrtwin Glück <odi@odi.ch>
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad5f97fa
    • David S. Miller's avatar
      Merge branch 'tun-races' · 2547496e
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      tun: address two syzbot reports
      
      Small changes addressing races discovered by syzbot.
      
      First patch is a cleanup.
      Second patch moves a mutex init sooner.
      Third patch makes sure each tfile gets its own napi enable flags.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2547496e
    • Eric Dumazet's avatar
      tun: napi flags belong to tfile · af3fb24e
      Eric Dumazet authored
      Since tun->flags might be shared by multiple tfile structures,
      it is better to make sure tun_get_user() is using the flags
      for the current tfile.
      
      Presence of the READ_ONCE() in tun_napi_frags_enabled() gave a hint
      of what could happen, but we need something stronger to please
      syzbot.
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 0 PID: 13647 Comm: syz-executor5 Not tainted 4.19.0-rc5+ #59
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:dev_gro_receive+0x132/0x2720 net/core/dev.c:5427
      Code: 48 c1 ea 03 80 3c 02 00 0f 85 6e 20 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 6e 10 49 8d bd d0 00 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 59 20 00 00 4d 8b a5 d0 00 00 00 31 ff 41 81 e4
      RSP: 0018:ffff8801c400f410 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8618d325
      RDX: 000000000000001a RSI: ffffffff86189f97 RDI: 00000000000000d0
      RBP: ffff8801c400f608 R08: ffff8801c8fb4300 R09: 0000000000000000
      R10: ffffed0038801ed7 R11: 0000000000000003 R12: ffff8801d327d358
      R13: 0000000000000000 R14: ffff8801c16dd8c0 R15: 0000000000000004
      FS:  00007fe003615700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fe1f3c43db8 CR3: 00000001bebb2000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       napi_gro_frags+0x3f4/0xc90 net/core/dev.c:5715
       tun_get_user+0x31d5/0x42a0 drivers/net/tun.c:1922
       tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:1967
       call_write_iter include/linux/fs.h:1808 [inline]
       new_sync_write fs/read_write.c:474 [inline]
       __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
       vfs_write+0x1fc/0x560 fs/read_write.c:549
       ksys_write+0x101/0x260 fs/read_write.c:598
       __do_sys_write fs/read_write.c:610 [inline]
       __se_sys_write fs/read_write.c:607 [inline]
       __x64_sys_write+0x73/0xb0 fs/read_write.c:607
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457579
      Code: 1d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fe003614c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457579
      RDX: 0000000000000012 RSI: 0000000020000000 RDI: 000000000000000a
      RBP: 000000000072c040 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe0036156d4
      R13: 00000000004c5574 R14: 00000000004d8e98 R15: 00000000ffffffff
      Modules linked in:
      
      RIP: 0010:dev_gro_receive+0x132/0x2720 net/core/dev.c:5427
      Code: 48 c1 ea 03 80 3c 02 00 0f 85 6e 20 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 6e 10 49 8d bd d0 00 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 59 20 00 00 4d 8b a5 d0 00 00 00 31 ff 41 81 e4
      RSP: 0018:ffff8801c400f410 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8618d325
      RDX: 000000000000001a RSI: ffffffff86189f97 RDI: 00000000000000d0
      RBP: ffff8801c400f608 R08: ffff8801c8fb4300 R09: 0000000000000000
      R10: ffffed0038801ed7 R11: 0000000000000003 R12: ffff8801d327d358
      R13: 0000000000000000 R14: ffff8801c16dd8c0 R15: 0000000000000004
      FS:  00007fe003615700(0000) GS:ffff8801dac00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fe1f3c43db8 CR3: 00000001bebb2000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      
      Fixes: 90e33d45 ("tun: enable napi_gro_frags() for TUN/TAP driver")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      af3fb24e