1. 10 1月, 2019 28 次提交
    • X
      sctp: initialize sin6_flowinfo for ipv6 addrs in sctp_inet6addr_event · fff7f717
      Xin Long 提交于
      [ Upstream commit 4a2eb0c37b4759416996fbb4c45b932500cf06d3 ]
      
      syzbot reported a kernel-infoleak, which is caused by an uninitialized
      field(sin6_flowinfo) of addr->a.v6 in sctp_inet6addr_event().
      The call trace is as below:
      
        BUG: KMSAN: kernel-infoleak in _copy_to_user+0x19a/0x230 lib/usercopy.c:33
        CPU: 1 PID: 8164 Comm: syz-executor2 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
          _copy_to_user+0x19a/0x230 lib/usercopy.c:33
          copy_to_user include/linux/uaccess.h:183 [inline]
          sctp_getsockopt_local_addrs net/sctp/socket.c:5998 [inline]
          sctp_getsockopt+0x15248/0x186f0 net/sctp/socket.c:7477
          sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2937
          __sys_getsockopt+0x489/0x550 net/socket.c:1939
          __do_sys_getsockopt net/socket.c:1950 [inline]
          __se_sys_getsockopt+0xe1/0x100 net/socket.c:1947
          __x64_sys_getsockopt+0x62/0x80 net/socket.c:1947
          do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
          entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      sin6_flowinfo is not really used by SCTP, so it will be fixed by simply
      setting it to 0.
      
      The issue exists since very beginning.
      Thanks Alexander for the reproducer provided.
      
      Reported-by: syzbot+ad5d327e6936a2e284be@syzkaller.appspotmail.com
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fff7f717
    • J
      qmi_wwan: Add support for Fibocom NL678 series · 2ec3976e
      Jörgen Storvist 提交于
      [ Upstream commit 7c3db4105ce8d69bcb5c04bfa9acd1e9119af8d5 ]
      
      Added support for Fibocom NL678 series cellular module QMI interface.
      Using QMI_QUIRK_SET_DTR required for Qualcomm MDM9x40 series chipsets.
      Signed-off-by: NJörgen Storvist <jorgen.storvist@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ec3976e
    • J
      qmi_wwan: Added support for Telit LN940 series · b7934b17
      Jörgen Storvist 提交于
      [ Upstream commit 1986af16e8ed355822600c24b3d2f0be46b573df ]
      
      Added support for the Telit LN940 series cellular modules QMI interface.
      QMI_QUIRK_SET_DTR quirk requied for Qualcomm MDM9x40 chipset.
      Signed-off-by: NJörgen Storvist <jorgen.storvist@gmail.com>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7934b17
    • J
      qmi_wwan: Added support for Fibocom NL668 series · a47e4db7
      Jörgen Storvist 提交于
      [ Upstream commit 110a1cc28bc383adb4885eff27e18c61ddebffb4 ]
      
      Added support for Fibocom NL668 series QMI interface.
      Using QMI_QUIRK_SET_DTR required for Qualcomm MDM9x07 chipsets.
      Signed-off-by: NJörgen Storvist <jorgen.storvist@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a47e4db7
    • C
      ptr_ring: wrap back ->producer in __ptr_ring_swap_queue() · 6e365672
      Cong Wang 提交于
      [ Upstream commit aff6db454599d62191aabc208930e891748e4322 ]
      
      __ptr_ring_swap_queue() tries to move pointers from the old
      ring to the new one, but it forgets to check if ->producer
      is beyond the new size at the end of the operation. This leads
      to an out-of-bound access in __ptr_ring_produce() as reported
      by syzbot.
      
      Reported-by: syzbot+8993c0fa96d57c399735@syzkaller.appspotmail.com
      Fixes: 5d49de53 ("ptr_ring: resize support")
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e365672
    • W
      packet: validate address length if non-zero · 4037ce1b
      Willem de Bruijn 提交于
      [ Upstream commit 6b8d95f1795c42161dc0984b6863e95d6acf24ed ]
      
      Validate packet socket address length if a length is given. Zero
      length is equivalent to not setting an address.
      
      Fixes: 99137b7888f4 ("packet: validate address length")
      Reported-by: NIdo Schimmel <idosch@idosch.org>
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4037ce1b
    • W
      packet: validate address length · a35c9c17
      Willem de Bruijn 提交于
      [ Upstream commit 99137b7888f4058087895d035d81c6b2d31015c5 ]
      
      Packet sockets with SOCK_DGRAM may pass an address for use in
      dev_hard_header. Ensure that it is of sufficient length.
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a35c9c17
    • C
      net/wan: fix a double free in x25_asy_open_tty() · 781e26ad
      Cong Wang 提交于
      [ Upstream commit d5c7c745f254c6cb98b3b3f15fe789b8bd770c72 ]
      
      When x25_asy_open() fails, it already cleans up by itself,
      so its caller doesn't need to free the memory again.
      
      It seems we still have to call x25_asy_free() to clear the SLF_INUSE
      bit, so just set these pointers to NULL after kfree().
      
      Reported-and-tested-by: syzbot+5e5e969e525129229052@syzkaller.appspotmail.com
      Fixes: 3b780bed ("x25_asy: Free x25_asy on x25_asy_open() failure.")
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      781e26ad
    • G
      net/tls: allocate tls context using GFP_ATOMIC · f624d95c
      Ganesh Goudar 提交于
      [ Upstream commit c6ec179a0082e2e76e3a72050c2b99d3d0f3da3f ]
      
      create_ctx can be called from atomic context, hence use
      GFP_ATOMIC instead of GFP_KERNEL.
      
      [  395.962599] BUG: sleeping function called from invalid context at mm/slab.h:421
      [  395.979896] in_atomic(): 1, irqs_disabled(): 0, pid: 16254, name: openssl
      [  395.996564] 2 locks held by openssl/16254:
      [  396.010492]  #0: 00000000347acb52 (sk_lock-AF_INET){+.+.}, at: do_tcp_setsockopt.isra.44+0x13b/0x9a0
      [  396.029838]  #1: 000000006c9552b5 (device_spinlock){+...}, at: tls_init+0x1d/0x280
      [  396.047675] CPU: 5 PID: 16254 Comm: openssl Tainted: G           O      4.20.0-rc6+ #25
      [  396.066019] Hardware name: Supermicro X10SRA-F/X10SRA-F, BIOS 2.0c 09/25/2017
      [  396.083537] Call Trace:
      [  396.096265]  dump_stack+0x5e/0x8b
      [  396.109876]  ___might_sleep+0x216/0x250
      [  396.123940]  kmem_cache_alloc_trace+0x1b0/0x240
      [  396.138800]  create_ctx+0x1f/0x60
      [  396.152504]  tls_init+0xbd/0x280
      [  396.166135]  tcp_set_ulp+0x191/0x2d0
      [  396.180035]  ? tcp_set_ulp+0x2c/0x2d0
      [  396.193960]  do_tcp_setsockopt.isra.44+0x148/0x9a0
      [  396.209013]  __sys_setsockopt+0x7c/0xe0
      [  396.223054]  __x64_sys_setsockopt+0x20/0x30
      [  396.237378]  do_syscall_64+0x4a/0x180
      [  396.251200]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: df9d4a178022 ("net/tls: sleeping function from invalid context")
      Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f624d95c
    • D
      net: stmmac: Fix an error code in probe() · 42e8bf85
      Dan Carpenter 提交于
      [ Upstream commit b26322d2ac6c1c1087af73856531bb836f6963ca ]
      
      The function should return an error if create_singlethread_workqueue()
      fails.
      
      Fixes: 34877a15 ("net: stmmac: Rework and fix TX Timeout code")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42e8bf85
    • M
      net/smc: fix TCP fallback socket release · e0280173
      Myungho Jung 提交于
      [ Upstream commit 78abe3d0dfad196959b1246003366e2610775ea6 ]
      
      clcsock can be released while kernel_accept() references it in TCP
      listen worker. Also, clcsock needs to wake up before released if TCP
      fallback is used and the clcsock is blocked by accept. Add a lock to
      safely release clcsock and call kernel_sock_shutdown() to wake up
      clcsock from accept in smc_release().
      
      Reported-by: syzbot+0bf2e01269f1274b4b03@syzkaller.appspotmail.com
      Reported-by: syzbot+e3132895630f957306bc@syzkaller.appspotmail.com
      Signed-off-by: NMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0280173
    • C
      netrom: fix locking in nr_find_socket() · a1bce719
      Cong Wang 提交于
      [ Upstream commit 7314f5480f3e37e570104dc5e0f28823ef849e72 ]
      
      nr_find_socket(), nr_find_peer() and nr_find_listener() lock the
      sock after finding it in the global list. However, the call path
      requires BH disabled for the sock lock consistently.
      
      Actually the locking is unnecessary at this point, we can just hold
      the sock refcnt to make sure it is not gone after we unlock the global
      list, and lock it later only when needed.
      
      Reported-and-tested-by: syzbot+f621cda8b7e598908efa@syzkaller.appspotmail.com
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1bce719
    • K
      net: phy: Fix the issue that netif always links up after resuming · 4d1edda0
      Kunihiko Hayashi 提交于
      [ Upstream commit 8742beb50f2db903d3b6d69ddd81d67ce9914453 ]
      
      Even though the link is down before entering hibernation,
      there is an issue that the network interface always links up after resuming
      from hibernation.
      
      If the link is still down before enabling the network interface,
      and after resuming from hibernation, the phydev->state is forcibly set
      to PHY_UP in mdio_bus_phy_restore(), and the link becomes up.
      
      In suspend sequence, only if the PHY is attached, mdio_bus_phy_suspend()
      calls phy_stop_machine(), and mdio_bus_phy_resume() calls
      phy_start_machine().
      In resume sequence, it's enough to do the same as mdio_bus_phy_resume()
      because the state has been preserved.
      
      This patch fixes the issue by calling phy_start_machine() in
      mdio_bus_phy_restore() in the same way as mdio_bus_phy_resume().
      
      Fixes: bc87922f ("phy: Move PHY PM operations into phy_device")
      Suggested-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d1edda0
    • A
      net: mvpp2: 10G modes aren't supported on all ports · e3ba5b26
      Antoine Tenart 提交于
      [ Upstream commit 006791772084383de779ef29f2e06f3a6e111e7d ]
      
      The mvpp2_phylink_validate() function sets all modes that are
      supported by a given PPv2 port. A recent change made all ports to
      advertise they support 10G modes in certain cases. This is not true,
      as only the port #0 can do so. This patch fixes it.
      
      Fixes: 01b3fd5ac97c ("net: mvpp2: fix detection of 10G SFP modules")
      Cc: Baruch Siach <baruch@tkos.co.il>
      Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3ba5b26
    • C
      net: macb: restart tx after tx used bit read · 5ea9c08a
      Claudiu Beznea 提交于
      [ Upstream commit 4298388574dae6168fa8940b3edc7ba965e8a7ab ]
      
      On some platforms (currently detected only on SAMA5D4) TX might stuck
      even the pachets are still present in DMA memories and TX start was
      issued for them. This happens due to race condition between MACB driver
      updating next TX buffer descriptor to be used and IP reading the same
      descriptor. In such a case, the "TX USED BIT READ" interrupt is asserted.
      GEM/MACB user guide specifies that if a "TX USED BIT READ" interrupt
      is asserted TX must be restarted. Restart TX if used bit is read and
      packets are present in software TX queue. Packets are removed from software
      TX queue if TX was successful for them (see macb_tx_interrupt()).
      Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
      Acked-by: NNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5ea9c08a
    • M
      net: ipv4: do not handle duplicate fragments as overlapping · d5f9565c
      Michal Kubecek 提交于
      [ Upstream commit ade446403bfb79d3528d56071a84b15351a139ad ]
      
      Since commit 7969e5c4 ("ip: discard IPv4 datagrams with overlapping
      segments.") IPv4 reassembly code drops the whole queue whenever an
      overlapping fragment is received. However, the test is written in a way
      which detects duplicate fragments as overlapping so that in environments
      with many duplicate packets, fragmented packets may be undeliverable.
      
      Add an extra test and for (potentially) duplicate fragment, only drop the
      new fragment rather than the whole queue. Only starting offset and length
      are checked, not the contents of the fragments as that would be too
      expensive. For similar reason, linear list ("run") of a rbtree node is not
      iterated, we only check if the new fragment is a subset of the interval
      covered by existing consecutive fragments.
      
      v2: instead of an exact check iterating through linear list of an rbtree
      node, only check if the new fragment is subset of the "run" (suggested
      by Eric Dumazet)
      
      Fixes: 7969e5c4 ("ip: discard IPv4 datagrams with overlapping segments.")
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5f9565c
    • E
      net/hamradio/6pack: use mod_timer() to rearm timers · acb70d28
      Eric Dumazet 提交于
      [ Upstream commit 202700e30740c6568b5a6943662f3829566dd533 ]
      
      Using del_timer() + add_timer() is generally unsafe on SMP,
      as noticed by syzbot. Use mod_timer() instead.
      
      kernel BUG at kernel/time/timer.c:1136!
      invalid opcode: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 1026 Comm: kworker/u4:4 Not tainted 4.20.0+ #2
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events_unbound flush_to_ldisc
      RIP: 0010:add_timer kernel/time/timer.c:1136 [inline]
      RIP: 0010:add_timer+0xa81/0x1470 kernel/time/timer.c:1134
      Code: 4d 89 7d 40 48 c7 85 70 fe ff ff 00 00 00 00 c7 85 7c fe ff ff ff ff ff ff 48 89 85 90 fe ff ff e9 e6 f7 ff ff e8 cf 42 12 00 <0f> 0b e8 c8 42 12 00 0f 0b e8 c1 42 12 00 4c 89 bd 60 fe ff ff e9
      RSP: 0018:ffff8880a7fdf5a8 EFLAGS: 00010293
      RAX: ffff8880a7846340 RBX: dffffc0000000000 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffffffff816f3ee1 RDI: ffff88808a514ff8
      RBP: ffff8880a7fdf760 R08: 0000000000000007 R09: ffff8880a7846c58
      R10: ffff8880a7846340 R11: 0000000000000000 R12: ffff88808a514ff8
      R13: ffff88808a514ff8 R14: ffff88808a514dc0 R15: 0000000000000030
      FS:  0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000000061c500 CR3: 00000000994d9000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       decode_prio_command drivers/net/hamradio/6pack.c:903 [inline]
       sixpack_decode drivers/net/hamradio/6pack.c:971 [inline]
       sixpack_receive_buf drivers/net/hamradio/6pack.c:457 [inline]
       sixpack_receive_buf+0xf9c/0x1470 drivers/net/hamradio/6pack.c:434
       tty_ldisc_receive_buf+0x164/0x1c0 drivers/tty/tty_buffer.c:465
       tty_port_default_receive_buf+0x114/0x190 drivers/tty/tty_port.c:38
       receive_buf drivers/tty/tty_buffer.c:481 [inline]
       flush_to_ldisc+0x3b2/0x590 drivers/tty/tty_buffer.c:533
       process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
       worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
       kthread+0x357/0x430 kernel/kthread.c:246
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Andreas Koensgen <ajk@comnets.uni-bremen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      acb70d28
    • E
      net: clear skb->tstamp in forwarding paths · 281731c8
      Eric Dumazet 提交于
      [ Upstream commit 8203e2d844d34af247a151d8ebd68553a6e91785 ]
      
      Sergey reported that forwarding was no longer working
      if fq packet scheduler was used.
      
      This is caused by the recent switch to EDT model, since incoming
      packets might have been timestamped by __net_timestamp()
      
      __net_timestamp() uses ktime_get_real(), while fq expects packets
      using CLOCK_MONOTONIC base.
      
      The fix is to clear skb->tstamp in forwarding paths.
      
      Fixes: 80b14dee ("net: Add a new socket option for a future transmit time.")
      Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NSergey Matyukevich <geomatsi@gmail.com>
      Tested-by: NSergey Matyukevich <geomatsi@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      281731c8
    • E
      isdn: fix kernel-infoleak in capi_unlocked_ioctl · ec820972
      Eric Dumazet 提交于
      [ Upstream commit d63967e475ae10f286dbd35e189cb241e0b1f284 ]
      
      Since capi_ioctl() copies 64 bytes after calling
      capi20_get_manufacturer() we need to ensure to not leak
      information to user.
      
      BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
      CPU: 0 PID: 11245 Comm: syz-executor633 Not tainted 4.20.0-rc7+ #2
      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+0x173/0x1d0 lib/dump_stack.c:113
       kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
       kmsan_internal_check_memory+0x9d4/0xb00 mm/kmsan/kmsan.c:704
       kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
       _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
       capi_ioctl include/linux/uaccess.h:177 [inline]
       capi_unlocked_ioctl+0x1a0b/0x1bf0 drivers/isdn/capi/capi.c:939
       do_vfs_ioctl+0xebd/0x2bf0 fs/ioctl.c:46
       ksys_ioctl fs/ioctl.c:713 [inline]
       __do_sys_ioctl fs/ioctl.c:720 [inline]
       __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718
       __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718
       do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
       entry_SYSCALL_64_after_hwframe+0x63/0xe7
      RIP: 0033:0x440019
      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 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffdd4659fb8 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440019
      RDX: 0000000020000080 RSI: 00000000c0044306 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
      R10: 0000000000000000 R11: 0000000000000213 R12: 00000000004018a0
      R13: 0000000000401930 R14: 0000000000000000 R15: 0000000000000000
      
      Local variable description: ----data.i@capi_unlocked_ioctl
      Variable was created at:
       capi_ioctl drivers/isdn/capi/capi.c:747 [inline]
       capi_unlocked_ioctl+0x82/0x1bf0 drivers/isdn/capi/capi.c:939
       do_vfs_ioctl+0xebd/0x2bf0 fs/ioctl.c:46
      
      Bytes 12-63 of 64 are uninitialized
      Memory access of size 64 starts at ffff88807ac5fce8
      Data copied to user address 0000000020000080
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec820972
    • W
      ip: validate header length on virtual device xmit · cde81154
      Willem de Bruijn 提交于
      [ Upstream commit cb9f1b783850b14cbd7f87d061d784a666dfba1f ]
      
      KMSAN detected read beyond end of buffer in vti and sit devices when
      passing truncated packets with PF_PACKET. The issue affects additional
      ip tunnel devices.
      
      Extend commit 76c0ddd8 ("ip6_tunnel: be careful when accessing the
      inner header") and commit ccfec9e5 ("ip_tunnel: be careful when
      accessing the inner header").
      
      Move the check to a separate helper and call at the start of each
      ndo_start_xmit function in net/ipv4 and net/ipv6.
      
      Minor changes:
      - convert dev_kfree_skb to kfree_skb on error path,
        as dev_kfree_skb calls consume_skb which is not for error paths.
      - use pskb_network_may_pull even though that is pedantic here,
        as the same as pskb_may_pull for devices without llheaders.
      - do not cache ipv6 hdrs if used only once
        (unsafe across pskb_may_pull, was more relevant to earlier patch)
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cde81154
    • E
      ipv6: tunnels: fix two use-after-free · 0d2b652b
      Eric Dumazet 提交于
      [ Upstream commit cbb49697d5512ce9e61b45ce75d3ee43d7ea5524 ]
      
      xfrm6_policy_check() might have re-allocated skb->head, we need
      to reload ipv6 header pointer.
      
      sysbot reported :
      
      BUG: KASAN: use-after-free in __ipv6_addr_type+0x302/0x32f net/ipv6/addrconf_core.c:40
      Read of size 4 at addr ffff888191b8cb70 by task syz-executor2/1304
      
      CPU: 0 PID: 1304 Comm: syz-executor2 Not tainted 4.20.0-rc7+ #356
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x244/0x39d lib/dump_stack.c:113
       print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
       __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
       __ipv6_addr_type+0x302/0x32f net/ipv6/addrconf_core.c:40
       ipv6_addr_type include/net/ipv6.h:403 [inline]
       ip6_tnl_get_cap+0x27/0x190 net/ipv6/ip6_tunnel.c:727
       ip6_tnl_rcv_ctl+0xdb/0x2a0 net/ipv6/ip6_tunnel.c:757
       vti6_rcv+0x336/0x8f3 net/ipv6/ip6_vti.c:321
       xfrm6_ipcomp_rcv+0x1a5/0x3a0 net/ipv6/xfrm6_protocol.c:132
       ip6_protocol_deliver_rcu+0x372/0x1940 net/ipv6/ip6_input.c:394
       ip6_input_finish+0x84/0x170 net/ipv6/ip6_input.c:434
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:443
      IPVS: ftp: loaded support on port[0] = 21
       ip6_mc_input+0x514/0x11c0 net/ipv6/ip6_input.c:537
       dst_input include/net/dst.h:450 [inline]
       ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ipv6_rcv+0x115/0x640 net/ipv6/ip6_input.c:272
       __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4973
       __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5083
       process_backlog+0x24e/0x7a0 net/core/dev.c:5923
       napi_poll net/core/dev.c:6346 [inline]
       net_rx_action+0x7fa/0x19b0 net/core/dev.c:6412
       __do_softirq+0x308/0xb7e kernel/softirq.c:292
       do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1027
       </IRQ>
       do_softirq.part.14+0x126/0x160 kernel/softirq.c:337
       do_softirq+0x19/0x20 kernel/softirq.c:340
       netif_rx_ni+0x521/0x860 net/core/dev.c:4569
       dev_loopback_xmit+0x287/0x8c0 net/core/dev.c:3576
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ip6_finish_output2+0x193a/0x2930 net/ipv6/ip6_output.c:84
       ip6_fragment+0x2b06/0x3850 net/ipv6/ip6_output.c:727
       ip6_finish_output+0x6b7/0xc50 net/ipv6/ip6_output.c:152
       NF_HOOK_COND include/linux/netfilter.h:278 [inline]
       ip6_output+0x232/0x9d0 net/ipv6/ip6_output.c:171
       dst_output include/net/dst.h:444 [inline]
       ip6_local_out+0xc5/0x1b0 net/ipv6/output_core.c:176
       ip6_send_skb+0xbc/0x340 net/ipv6/ip6_output.c:1727
       ip6_push_pending_frames+0xc5/0xf0 net/ipv6/ip6_output.c:1747
       rawv6_push_pending_frames net/ipv6/raw.c:615 [inline]
       rawv6_sendmsg+0x3a3e/0x4b40 net/ipv6/raw.c:945
      kobject: 'queues' (0000000089e6eea2): kobject_add_internal: parent: 'tunl0', set: '<NULL>'
      kobject: 'queues' (0000000089e6eea2): kobject_uevent_env
       inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
      kobject: 'queues' (0000000089e6eea2): kobject_uevent_env: filter function caused the event to drop!
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:631
       sock_write_iter+0x35e/0x5c0 net/socket.c:900
       call_write_iter include/linux/fs.h:1857 [inline]
       new_sync_write fs/read_write.c:474 [inline]
       __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
      kobject: 'rx-0' (00000000e2d902d9): kobject_add_internal: parent: 'queues', set: 'queues'
      kobject: 'rx-0' (00000000e2d902d9): kobject_uevent_env
       vfs_write+0x1fc/0x560 fs/read_write.c:549
       ksys_write+0x101/0x260 fs/read_write.c:598
      kobject: 'rx-0' (00000000e2d902d9): fill_kobj_path: path = '/devices/virtual/net/tunl0/queues/rx-0'
       __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
      kobject: 'tx-0' (00000000443b70ac): kobject_add_internal: parent: 'queues', set: 'queues'
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x457669
      Code: fd b3 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 b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f9bd200bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457669
      RDX: 000000000000058f RSI: 00000000200033c0 RDI: 0000000000000003
      kobject: 'tx-0' (00000000443b70ac): kobject_uevent_env
      RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9bd200c6d4
      R13: 00000000004c2dcc R14: 00000000004da398 R15: 00000000ffffffff
      
      Allocated by task 1304:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
       __do_kmalloc_node mm/slab.c:3684 [inline]
       __kmalloc_node_track_caller+0x50/0x70 mm/slab.c:3698
       __kmalloc_reserve.isra.41+0x41/0xe0 net/core/skbuff.c:140
       __alloc_skb+0x155/0x760 net/core/skbuff.c:208
      kobject: 'tx-0' (00000000443b70ac): fill_kobj_path: path = '/devices/virtual/net/tunl0/queues/tx-0'
       alloc_skb include/linux/skbuff.h:1011 [inline]
       __ip6_append_data.isra.49+0x2f1a/0x3f50 net/ipv6/ip6_output.c:1450
       ip6_append_data+0x1bc/0x2d0 net/ipv6/ip6_output.c:1619
       rawv6_sendmsg+0x15ab/0x4b40 net/ipv6/raw.c:938
       inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
       sock_sendmsg_nosec net/socket.c:621 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:631
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116
       __sys_sendmsg+0x11d/0x280 net/socket.c:2154
       __do_sys_sendmsg net/socket.c:2163 [inline]
       __se_sys_sendmsg net/socket.c:2161 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      kobject: 'gre0' (00000000cb1b2d7b): kobject_add_internal: parent: 'net', set: 'devices'
      
      Freed by task 1304:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:448
       set_track mm/kasan/kasan.c:460 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
       kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
       __cache_free mm/slab.c:3498 [inline]
       kfree+0xcf/0x230 mm/slab.c:3817
       skb_free_head+0x93/0xb0 net/core/skbuff.c:553
       pskb_expand_head+0x3b2/0x10d0 net/core/skbuff.c:1498
       __pskb_pull_tail+0x156/0x18a0 net/core/skbuff.c:1896
       pskb_may_pull include/linux/skbuff.h:2188 [inline]
       _decode_session6+0xd11/0x14d0 net/ipv6/xfrm6_policy.c:150
       __xfrm_decode_session+0x71/0x140 net/xfrm/xfrm_policy.c:3272
      kobject: 'gre0' (00000000cb1b2d7b): kobject_uevent_env
       __xfrm_policy_check+0x380/0x2c40 net/xfrm/xfrm_policy.c:3322
       __xfrm_policy_check2 include/net/xfrm.h:1170 [inline]
       xfrm_policy_check include/net/xfrm.h:1175 [inline]
       xfrm6_policy_check include/net/xfrm.h:1185 [inline]
       vti6_rcv+0x4bd/0x8f3 net/ipv6/ip6_vti.c:316
       xfrm6_ipcomp_rcv+0x1a5/0x3a0 net/ipv6/xfrm6_protocol.c:132
       ip6_protocol_deliver_rcu+0x372/0x1940 net/ipv6/ip6_input.c:394
       ip6_input_finish+0x84/0x170 net/ipv6/ip6_input.c:434
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:443
       ip6_mc_input+0x514/0x11c0 net/ipv6/ip6_input.c:537
       dst_input include/net/dst.h:450 [inline]
       ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
       NF_HOOK include/linux/netfilter.h:289 [inline]
       ipv6_rcv+0x115/0x640 net/ipv6/ip6_input.c:272
       __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4973
       __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5083
       process_backlog+0x24e/0x7a0 net/core/dev.c:5923
      kobject: 'gre0' (00000000cb1b2d7b): fill_kobj_path: path = '/devices/virtual/net/gre0'
       napi_poll net/core/dev.c:6346 [inline]
       net_rx_action+0x7fa/0x19b0 net/core/dev.c:6412
       __do_softirq+0x308/0xb7e kernel/softirq.c:292
      
      The buggy address belongs to the object at ffff888191b8cac0
       which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 176 bytes inside of
       512-byte region [ffff888191b8cac0, ffff888191b8ccc0)
      The buggy address belongs to the page:
      page:ffffea000646e300 count:1 mapcount:0 mapping:ffff8881da800940 index:0x0
      flags: 0x2fffc0000000200(slab)
      raw: 02fffc0000000200 ffffea0006eaaa48 ffffea00065356c8 ffff8881da800940
      raw: 0000000000000000 ffff888191b8c0c0 0000000100000006 0000000000000000
      page dumped because: kasan: bad access detected
      kobject: 'queues' (000000005fd6226e): kobject_add_internal: parent: 'gre0', set: '<NULL>'
      
      Memory state around the buggy address:
       ffff888191b8ca00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff888191b8ca80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
      >ffff888191b8cb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                   ^
       ffff888191b8cb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff888191b8cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: 0d3c703a ("ipv6: Cleanup IPv6 tunnel receive path")
      Fixes: ed1efb2a ("ipv6: Add support for IPsec virtual tunnel interfaces")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d2b652b
    • C
      ipv6: explicitly initialize udp6_addr in udp_sock_create6() · cae3c9cf
      Cong Wang 提交于
      [ Upstream commit fb24274546310872eeeaf3d1d53799d8414aa0f2 ]
      
      syzbot reported the use of uninitialized udp6_addr::sin6_scope_id.
      We can just set ::sin6_scope_id to zero, as tunnels are unlikely
      to use an IPv6 address that needs a scope id and there is no
      interface to bind in this context.
      
      For net-next, it looks different as we have cfg->bind_ifindex there
      so we can probably call ipv6_iface_scope_id().
      
      Same for ::sin6_flowinfo, tunnels don't use it.
      
      Fixes: 8024e028 ("udp: Add udp_sock_create for UDP tunnels to open listener socket")
      Reported-by: syzbot+c56449ed3652e6720f30@syzkaller.appspotmail.com
      Cc: Jon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cae3c9cf
    • G
      ipv4: Fix potential Spectre v1 vulnerability · 360fb1db
      Gustavo A. R. Silva 提交于
      [ Upstream commit 5648451e30a0d13d11796574919a359025d52cce ]
      
      vr.vifi is indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      net/ipv4/ipmr.c:1616 ipmr_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      net/ipv4/ipmr.c:1690 ipmr_compat_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      
      Fix this by sanitizing vr.vifi before using it to index mrt->vif_table'
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      360fb1db
    • G
      ip6mr: Fix potential Spectre v1 vulnerability · 32403fd3
      Gustavo A. R. Silva 提交于
      [ Upstream commit 69d2c86766da2ded2b70281f1bf242cb0d58a778 ]
      
      vr.mifi is indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      net/ipv6/ip6mr.c:1845 ip6mr_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      net/ipv6/ip6mr.c:1919 ip6mr_compat_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      
      Fix this by sanitizing vr.mifi before using it to index mrt->vif_table'
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32403fd3
    • W
      ieee802154: lowpan_header_create check must check daddr · 110c877d
      Willem de Bruijn 提交于
      [ Upstream commit 40c3ff6d5e0809505a067dd423c110c5658c478c ]
      
      Packet sockets may call dev_header_parse with NULL daddr. Make
      lowpan_header_ops.create fail.
      
      Fixes: 87a93e4e ("ieee802154: change needed headroom/tailroom")
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Acked-by: NAlexander Aring <aring@mojatatu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      110c877d
    • T
      ibmveth: fix DMA unmap error in ibmveth_xmit_start error path · 42b676c7
      Tyrel Datwyler 提交于
      [ Upstream commit 756af9c642329d54f048bac2a62f829b391f6944 ]
      
      Commit 33a48ab1 ("ibmveth: Fix DMA unmap error") fixed an issue in the
      normal code path of ibmveth_xmit_start() that was originally introduced by
      Commit 6e8ab30e ("ibmveth: Add scatter-gather support"). This original
      fix missed the error path where dma_unmap_page is wrongly called on the
      header portion in descs[0] which was mapped with dma_map_single. As a
      result a failure to DMA map any of the frags results in a dmesg warning
      when CONFIG_DMA_API_DEBUG is enabled.
      
      ------------[ cut here ]------------
      DMA-API: ibmveth 30000002: device driver frees DMA memory with wrong function
        [device address=0x000000000a430000] [size=172 bytes] [mapped as page] [unmapped as single]
      WARNING: CPU: 1 PID: 8426 at kernel/dma/debug.c:1085 check_unmap+0x4fc/0xe10
      ...
      <snip>
      ...
      DMA-API: Mapped at:
      ibmveth_start_xmit+0x30c/0xb60
      dev_hard_start_xmit+0x100/0x450
      sch_direct_xmit+0x224/0x490
      __qdisc_run+0x20c/0x980
      __dev_queue_xmit+0x1bc/0xf20
      
      This fixes the API misuse by unampping descs[0] with dma_unmap_single.
      
      Fixes: 6e8ab30e ("ibmveth: Add scatter-gather support")
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42b676c7
    • L
      gro_cell: add napi_disable in gro_cells_destroy · 3c859ade
      Lorenzo Bianconi 提交于
      [ Upstream commit 8e1da73acded4751a93d4166458a7e640f37d26c ]
      
      Add napi_disable routine in gro_cells_destroy since starting from
      commit c42858ea ("gro_cells: remove spinlock protecting receive
      queues") gro_cell_poll and gro_cells_destroy can run concurrently on
      napi_skbs list producing a kernel Oops if the tunnel interface is
      removed while gro_cell_poll is running. The following Oops has been
      triggered removing a vxlan device while the interface is receiving
      traffic
      
      [ 5628.948853] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      [ 5628.949981] PGD 0 P4D 0
      [ 5628.950308] Oops: 0002 [#1] SMP PTI
      [ 5628.950748] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 4.20.0-rc6+ #41
      [ 5628.952940] RIP: 0010:gro_cell_poll+0x49/0x80
      [ 5628.955615] RSP: 0018:ffffc9000004fdd8 EFLAGS: 00010202
      [ 5628.956250] RAX: 0000000000000000 RBX: ffffe8ffffc08150 RCX: 0000000000000000
      [ 5628.957102] RDX: 0000000000000000 RSI: ffff88802356bf00 RDI: ffffe8ffffc08150
      [ 5628.957940] RBP: 0000000000000026 R08: 0000000000000000 R09: 0000000000000000
      [ 5628.958803] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000040
      [ 5628.959661] R13: ffffe8ffffc08100 R14: 0000000000000000 R15: 0000000000000040
      [ 5628.960682] FS:  0000000000000000(0000) GS:ffff88803ea00000(0000) knlGS:0000000000000000
      [ 5628.961616] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 5628.962359] CR2: 0000000000000008 CR3: 000000000221c000 CR4: 00000000000006b0
      [ 5628.963188] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 5628.964034] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 5628.964871] Call Trace:
      [ 5628.965179]  net_rx_action+0xf0/0x380
      [ 5628.965637]  __do_softirq+0xc7/0x431
      [ 5628.966510]  run_ksoftirqd+0x24/0x30
      [ 5628.966957]  smpboot_thread_fn+0xc5/0x160
      [ 5628.967436]  kthread+0x113/0x130
      [ 5628.968283]  ret_from_fork+0x3a/0x50
      [ 5628.968721] Modules linked in:
      [ 5628.969099] CR2: 0000000000000008
      [ 5628.969510] ---[ end trace 9d9dedc7181661fe ]---
      [ 5628.970073] RIP: 0010:gro_cell_poll+0x49/0x80
      [ 5628.972965] RSP: 0018:ffffc9000004fdd8 EFLAGS: 00010202
      [ 5628.973611] RAX: 0000000000000000 RBX: ffffe8ffffc08150 RCX: 0000000000000000
      [ 5628.974504] RDX: 0000000000000000 RSI: ffff88802356bf00 RDI: ffffe8ffffc08150
      [ 5628.975462] RBP: 0000000000000026 R08: 0000000000000000 R09: 0000000000000000
      [ 5628.976413] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000040
      [ 5628.977375] R13: ffffe8ffffc08100 R14: 0000000000000000 R15: 0000000000000040
      [ 5628.978296] FS:  0000000000000000(0000) GS:ffff88803ea00000(0000) knlGS:0000000000000000
      [ 5628.979327] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 5628.980044] CR2: 0000000000000008 CR3: 000000000221c000 CR4: 00000000000006b0
      [ 5628.980929] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 5628.981736] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 5628.982409] Kernel panic - not syncing: Fatal exception in interrupt
      [ 5628.983307] Kernel Offset: disabled
      
      Fixes: c42858ea ("gro_cells: remove spinlock protecting receive queues")
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c859ade
    • C
      ax25: fix a use-after-free in ax25_fillin_cb() · 3e881d87
      Cong Wang 提交于
      [ Upstream commit c433570458e49bccea5c551df628d058b3526289 ]
      
      There are multiple issues here:
      
      1. After freeing dev->ax25_ptr, we need to set it to NULL otherwise
         we may use a dangling pointer.
      
      2. There is a race between ax25_setsockopt() and device notifier as
         reported by syzbot. Close it by holding RTNL lock.
      
      3. We need to test if dev->ax25_ptr is NULL before using it.
      
      Reported-and-tested-by: syzbot+ae6bb869cbed29b29040@syzkaller.appspotmail.com
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e881d87
  2. 29 12月, 2018 12 次提交