1. 05 May, 2019 34 commits
    • Oleksandr Natalenko's avatar
      Merge tag 'v5.0.13' into pf-5.0 · e7743d7f
      Oleksandr Natalenko authored
      This is the 5.0.13 stable release
      e7743d7f
    • Greg Kroah-Hartman's avatar
      Linux 5.0.13 · e5b9547b
      Greg Kroah-Hartman authored
      e5b9547b
    • Rafael J. Wysocki's avatar
      ath10k: Drop WARN_ON()s that always trigger during system resume · d467f3ac
      Rafael J. Wysocki authored
      commit 9e80ad37 upstream.
      
      ath10k_mac_vif_chan() always returns an error for the given vif
      during system-wide resume which reliably triggers two WARN_ON()s
      in ath10k_bss_info_changed() and they are not particularly
      useful in that code path, so drop them.
      
      Tested: QCA6174 hw3.2 PCI with WLAN.RM.2.0-00180-QCARMSWPZ-1
      Tested: QCA6174 hw3.2 SDIO with WLAN.RMH.4.4.1-00007-QCARMSWP-1
      
      Fixes: cd93b83a ("ath10k: support for multicast rate control")
      Fixes: f279294e ("ath10k: add support for configuring management packet rate")
      Cc: stable@vger.kernel.org
      Reviewed-by: 's avatarBrian Norris <briannorris@chromium.org>
      Tested-by: 's avatarBrian Norris <briannorris@chromium.org>
      Tested-by: 's avatarClaire Chang <tientzu@chromium.org>
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: 's avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d467f3ac
    • Greg Kroah-Hartman's avatar
      iwlwifi: mvm: properly check debugfs dentry before using it · 3c13f6cd
      Greg Kroah-Hartman authored
      commit 154d4899 upstream.
      
      debugfs can now report an error code if something went wrong instead of
      just NULL.  So if the return value is to be used as a "real" dentry, it
      needs to be checked if it is an error before dereferencing it.
      
      This is now happening because of ff9fb72b ("debugfs: return error
      values, not NULL").  If multiple iwlwifi devices are in the system, this
      can cause problems when the driver attempts to create the main debugfs
      directory again.  Later on in the code we fail horribly by trying to
      dereference a pointer that is an error value.
      Reported-by: 's avatarLaura Abbott <labbott@redhat.com>
      Reported-by: 's avatarGabriel Ramirez <gabriello.ramirez@gmail.com>
      Cc: Johannes Berg <johannes.berg@intel.com>
      Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
      Cc: Luca Coelho <luciano.coelho@intel.com>
      Cc: Intel Linux Wireless <linuxwifi@intel.com>
      Cc: Kalle Valo <kvalo@codeaurora.org>
      Cc: stable <stable@vger.kernel.org> # 5.0
      Signed-off-by: 's avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c13f6cd
    • Greg Kroah-Hartman's avatar
      ALSA: line6: use dynamic buffers · c391e619
      Greg Kroah-Hartman authored
      commit e5c812e8 upstream.
      
      The line6 driver uses a lot of USB buffers off of the stack, which is
      not allowed on many systems, causing the driver to crash on some of
      them.  Fix this up by dynamically allocating the buffers with kmalloc()
      which allows for proper DMA-able memory.
      Reported-by: Christo Gouws's avatarChristo Gouws <gouws.christo@gmail.com>
      Reported-by: 's avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: Christo Gouws's avatarChristo Gouws <gouws.christo@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c391e619
    • Jim Mattson's avatar
      KVM: nVMX: Fix size checks in vmx_set_nested_state · 4c38bd0d
      Jim Mattson authored
      commit e8ab8d24 upstream.
      
      The size checks in vmx_nested_state are wrong because the calculations
      are made based on the size of a pointer to a struct kvm_nested_state
      rather than the size of a struct kvm_nested_state.
      Reported-by: 's avatarFelix Wilhelm  <fwilhelm@google.com>
      Signed-off-by: 's avatarJim Mattson <jmattson@google.com>
      Reviewed-by: 's avatarDrew Schmitt <dasch@google.com>
      Reviewed-by: 's avatarMarc Orr <marcorr@google.com>
      Reviewed-by: 's avatarPeter Shier <pshier@google.com>
      Reviewed-by: 's avatarKrish Sadhukhan <krish.sadhukhan@oracle.com>
      Fixes: 8fcc4b59
      Cc: stable@ver.kernel.org
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c38bd0d
    • Sean Christopherson's avatar
      KVM: x86: Whitelist port 0x7e for pre-incrementing %rip · 119ac69c
      Sean Christopherson authored
      commit 8764ed55 upstream.
      
      KVM's recent bug fix to update %rip after emulating I/O broke userspace
      that relied on the previous behavior of incrementing %rip prior to
      exiting to userspace.  When running a Windows XP guest on AMD hardware,
      Qemu may patch "OUT 0x7E" instructions in reaction to the OUT itself.
      Because KVM's old behavior was to increment %rip before exiting to
      userspace to handle the I/O, Qemu manually adjusted %rip to account for
      the OUT instruction.
      
      Arguably this is a userspace bug as KVM requires userspace to re-enter
      the kernel to complete instruction emulation before taking any other
      actions.  That being said, this is a bit of a grey area and breaking
      userspace that has worked for many years is bad.
      
      Pre-increment %rip on OUT to port 0x7e before exiting to userspace to
      hack around the issue.
      
      Fixes: 45def77e ("KVM: x86: update %rip after emulating IO")
      Reported-by: 's avatarSimon Becherer <simon@becherer.de>
      Reported-and-tested-by: 's avatarIakov Karpov <srid@rkmail.ru>
      Reported-by: gabriele balducci's avatarGabriele Balducci <balducci@units.it>
      Reported-by: 's avatarAntti Antinoja <reader@fennosys.fi>
      Cc: stable@vger.kernel.org
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: 's avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      119ac69c
    • Jakub Kicinski's avatar
      net/tls: fix copy to fragments in reencrypt · a31a8f55
      Jakub Kicinski authored
      [ Upstream commit eb3d38d5 ]
      
      Fragments may contain data from other records so we have to account
      for that when we calculate the destination and max length of copy we
      can perform.  Note that 'offset' is the offset within the message,
      so it can't be passed as offset within the frag..
      
      Here skb_store_bits() would have realised the call is wrong and
      simply not copy data.
      
      Fixes: 4799ac81 ("tls: Add rx inline crypto offload")
      Signed-off-by: 's avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: 's avatarJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a31a8f55
    • Jakub Kicinski's avatar
      net/tls: don't copy negative amounts of data in reencrypt · f7f4d4b8
      Jakub Kicinski authored
      [ Upstream commit 97e1caa5 ]
      
      There is no guarantee the record starts before the skb frags.
      If we don't check for this condition copy amount will get
      negative, leading to reads and writes to random memory locations.
      Familiar hilarity ensues.
      
      Fixes: 4799ac81 ("tls: Add rx inline crypto offload")
      Signed-off-by: 's avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: 's avatarJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7f4d4b8
    • Michael Chan's avatar
      bnxt_en: Fix uninitialized variable usage in bnxt_rx_pkt(). · 126255f1
      Michael Chan authored
      [ Upstream commit 0b397b17 ]
      
      In bnxt_rx_pkt(), if the driver encounters BD errors, it will recycle
      the buffers and jump to the end where the uninitailized variable "len"
      is referenced.  Fix it by adding a new jump label that will skip
      the length update.  This is the most correct fix since the length
      may not be valid when we get this type of error.
      
      Fixes: 6a8788f2 ("bnxt_en: add support for software dynamic interrupt moderation")
      Reported-by: Nathan Chancellor's avatarNathan Chancellor <natechancellor@gmail.com>
      Cc: Nathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: 's avatarMichael Chan <michael.chan@broadcom.com>
      Reviewed-by: Nathan Chancellor's avatarNathan Chancellor <natechancellor@gmail.com>
      Tested-by: Nathan Chancellor's avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      126255f1
    • Michael Chan's avatar
      bnxt_en: Fix statistics context reservation logic. · 95fc8b4b
      Michael Chan authored
      [ Upstream commit 3f93cd3f ]
      
      In an earlier commit that fixes the number of stats contexts to
      reserve for the RDMA driver, we added a function parameter to pass in
      the number of stats contexts to all the relevant functions.  The passed
      in parameter should have been used to set the enables field of the
      firmware message.
      
      Fixes: 780baad4 ("bnxt_en: Reserve 1 stat_ctx for RDMA driver.")
      Signed-off-by: 's avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      95fc8b4b
    • Michael Chan's avatar
      bnxt_en: Pass correct extended TX port statistics size to firmware. · 1c38ed7b
      Michael Chan authored
      [ Upstream commit ad361adf ]
      
      If driver determines that extended TX port statistics are not supported
      or allocation of the data structure fails, make sure to pass 0 TX stats
      size to firmware to disable it.  The firmware returned TX stats size should
      also be set to 0 for consistency.  This will prevent
      bnxt_get_ethtool_stats() from accessing the NULL TX stats pointer in
      case there is mismatch between firmware and driver.
      
      Fixes: 36e53349 ("bnxt_en: Add additional extended port statistics.")
      Signed-off-by: 's avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1c38ed7b
    • Michael Chan's avatar
      bnxt_en: Fix possible crash in bnxt_hwrm_ring_free() under error conditions. · 4348cae3
      Michael Chan authored
      [ Upstream commit 1f83391b ]
      
      If we encounter errors during open and proceed to clean up,
      bnxt_hwrm_ring_free() may crash if the rings we try to free have never
      been allocated.  bnxt_cp_ring_for_rx() or bnxt_cp_ring_for_tx()
      may reference pointers that have not been allocated.
      
      Fix it by checking for valid fw_ring_id first before calling
      bnxt_cp_ring_for_rx() or bnxt_cp_ring_for_tx().
      
      Fixes: 2c61d211 ("bnxt_en: Add helper functions to get firmware CP ring ID.")
      Signed-off-by: 's avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4348cae3
    • Vasundhara Volam's avatar
      bnxt_en: Free short FW command HWRM memory in error path in bnxt_init_one() · 76dba4d8
      Vasundhara Volam authored
      [ Upstream commit f9099d61 ]
      
      In the bnxt_init_one() error path, short FW command request memory
      is not freed. This patch fixes it.
      
      Fixes: e605db80 ("bnxt_en: Support for Short Firmware Message")
      Signed-off-by: 's avatarVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: 's avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76dba4d8
    • Michael Chan's avatar
      bnxt_en: Improve multicast address setup logic. · 4aaaa658
      Michael Chan authored
      [ Upstream commit b4e30e8e ]
      
      The driver builds a list of multicast addresses and sends it to the
      firmware when the driver's ndo_set_rx_mode() is called.  In rare
      cases, the firmware can fail this call if internal resources to
      add multicast addresses are exhausted.  In that case, we should
      try the call again by setting the ALL_MCAST flag which is more
      guaranteed to succeed.
      
      Fixes: c0c050c5 ("bnxt_en: New Broadcom ethernet driver.")
      Signed-off-by: 's avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4aaaa658
    • Eric Dumazet's avatar
      udp: fix GRO packet of death · 7a0d81d1
      Eric Dumazet authored
      [ Upstream commit 4dd2b82d ]
      
      syzbot was able to crash host by sending UDP packets with a 0 payload.
      
      TCP does not have this issue since we do not aggregate packets without
      payload.
      
      Since dev_gro_receive() sets gso_size based on skb_gro_len(skb)
      it seems not worth trying to cope with padded packets.
      
      BUG: KASAN: slab-out-of-bounds in skb_gro_receive+0xf5f/0x10e0 net/core/skbuff.c:3826
      Read of size 16 at addr ffff88808893fff0 by task syz-executor612/7889
      
      CPU: 0 PID: 7889 Comm: syz-executor612 Not tainted 5.1.0-rc7+ #96
      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+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       __asan_report_load16_noabort+0x14/0x20 mm/kasan/generic_report.c:133
       skb_gro_receive+0xf5f/0x10e0 net/core/skbuff.c:3826
       udp_gro_receive_segment net/ipv4/udp_offload.c:382 [inline]
       call_gro_receive include/linux/netdevice.h:2349 [inline]
       udp_gro_receive+0xb61/0xfd0 net/ipv4/udp_offload.c:414
       udp4_gro_receive+0x763/0xeb0 net/ipv4/udp_offload.c:478
       inet_gro_receive+0xe72/0x1110 net/ipv4/af_inet.c:1510
       dev_gro_receive+0x1cd0/0x23c0 net/core/dev.c:5581
       napi_gro_frags+0x36b/0xd10 net/core/dev.c:5843
       tun_get_user+0x2f24/0x3fb0 drivers/net/tun.c:1981
       tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2027
       call_write_iter include/linux/fs.h:1866 [inline]
       do_iter_readv_writev+0x5e1/0x8e0 fs/read_write.c:681
       do_iter_write fs/read_write.c:957 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:938
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1002
       do_writev+0x15e/0x370 fs/read_write.c:1037
       __do_sys_writev fs/read_write.c:1110 [inline]
       __se_sys_writev fs/read_write.c:1107 [inline]
       __x64_sys_writev+0x75/0xb0 fs/read_write.c:1107
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x441cc0
      Code: 05 48 3d 01 f0 ff ff 0f 83 9d 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 3d 51 93 29 00 00 75 14 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 74 09 fc ff c3 48 83 ec 08 e8 ba 2b 00 00
      RSP: 002b:00007ffe8c716118 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
      RAX: ffffffffffffffda RBX: 00007ffe8c716150 RCX: 0000000000441cc0
      RDX: 0000000000000001 RSI: 00007ffe8c716170 RDI: 00000000000000f0
      RBP: 0000000000000000 R08: 000000000000ffff R09: 0000000000a64668
      R10: 0000000020000040 R11: 0000000000000246 R12: 000000000000c2d9
      R13: 0000000000402b50 R14: 0000000000000000 R15: 0000000000000000
      
      Allocated by task 5143:
       save_stack+0x45/0xd0 mm/kasan/common.c:75
       set_track mm/kasan/common.c:87 [inline]
       __kasan_kmalloc mm/kasan/common.c:497 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470
       kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:505
       slab_post_alloc_hook mm/slab.h:437 [inline]
       slab_alloc mm/slab.c:3393 [inline]
       kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3555
       mm_alloc+0x1d/0xd0 kernel/fork.c:1030
       bprm_mm_init fs/exec.c:363 [inline]
       __do_execve_file.isra.0+0xaa3/0x23f0 fs/exec.c:1791
       do_execveat_common fs/exec.c:1865 [inline]
       do_execve fs/exec.c:1882 [inline]
       __do_sys_execve fs/exec.c:1958 [inline]
       __se_sys_execve fs/exec.c:1953 [inline]
       __x64_sys_execve+0x8f/0xc0 fs/exec.c:1953
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 5351:
       save_stack+0x45/0xd0 mm/kasan/common.c:75
       set_track mm/kasan/common.c:87 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:459
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:467
       __cache_free mm/slab.c:3499 [inline]
       kmem_cache_free+0x86/0x260 mm/slab.c:3765
       __mmdrop+0x238/0x320 kernel/fork.c:677
       mmdrop include/linux/sched/mm.h:49 [inline]
       finish_task_switch+0x47b/0x780 kernel/sched/core.c:2746
       context_switch kernel/sched/core.c:2880 [inline]
       __schedule+0x81b/0x1cc0 kernel/sched/core.c:3518
       preempt_schedule_irq+0xb5/0x140 kernel/sched/core.c:3745
       retint_kernel+0x1b/0x2d
       arch_local_irq_restore arch/x86/include/asm/paravirt.h:767 [inline]
       kmem_cache_free+0xab/0x260 mm/slab.c:3766
       anon_vma_chain_free mm/rmap.c:134 [inline]
       unlink_anon_vmas+0x2ba/0x870 mm/rmap.c:401
       free_pgtables+0x1af/0x2f0 mm/memory.c:394
       exit_mmap+0x2d1/0x530 mm/mmap.c:3144
       __mmput kernel/fork.c:1046 [inline]
       mmput+0x15f/0x4c0 kernel/fork.c:1067
       exec_mmap fs/exec.c:1046 [inline]
       flush_old_exec+0x8d9/0x1c20 fs/exec.c:1279
       load_elf_binary+0x9bc/0x53f0 fs/binfmt_elf.c:864
       search_binary_handler fs/exec.c:1656 [inline]
       search_binary_handler+0x17f/0x570 fs/exec.c:1634
       exec_binprm fs/exec.c:1698 [inline]
       __do_execve_file.isra.0+0x1394/0x23f0 fs/exec.c:1818
       do_execveat_common fs/exec.c:1865 [inline]
       do_execve fs/exec.c:1882 [inline]
       __do_sys_execve fs/exec.c:1958 [inline]
       __se_sys_execve fs/exec.c:1953 [inline]
       __x64_sys_execve+0x8f/0xc0 fs/exec.c:1953
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff88808893f7c0
       which belongs to the cache mm_struct of size 1496
      The buggy address is located 600 bytes to the right of
       1496-byte region [ffff88808893f7c0, ffff88808893fd98)
      The buggy address belongs to the page:
      page:ffffea0002224f80 count:1 mapcount:0 mapping:ffff88821bc40ac0 index:0xffff88808893f7c0 compound_mapcount: 0
      flags: 0x1fffc0000010200(slab|head)
      raw: 01fffc0000010200 ffffea00025b4f08 ffffea00027b9d08 ffff88821bc40ac0
      raw: ffff88808893f7c0 ffff88808893e440 0000000100000001 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88808893fe80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88808893ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88808893ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                   ^
       ffff888088940000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff888088940080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Fixes: e20cf8d3 ("udp: implement GRO for plain UDP sockets.")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a0d81d1
    • Paolo Abeni's avatar
      udp: fix GRO reception in case of length mismatch · 8858d723
      Paolo Abeni authored
      [ Upstream commit 21f1b8a6 ]
      
      Currently, the UDP GRO code path does bad things on some edge
      conditions - Aggregation can happen even on packet with different
      lengths.
      
      Fix the above by rewriting the 'complete' condition for GRO
      packets. While at it, note explicitly that we allow merging the
      first packet per burst below gso_size.
      Reported-by: 's avatarSean Tong <seantong114@gmail.com>
      Fixes: e20cf8d3 ("udp: implement GRO for plain UDP sockets.")
      Signed-off-by: 's avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8858d723
    • Eric Dumazet's avatar
      tcp: add sanity tests in tcp_add_backlog() · b58d12d3
      Eric Dumazet authored
      [ Upstream commit ca2fe295 ]
      
      Richard and Bruno both reported that my commit added a bug,
      and Bruno was able to determine the problem came when a segment
      wih a FIN packet was coalesced to a prior one in tcp backlog queue.
      
      It turns out the header prediction in tcp_rcv_established()
      looks back to TCP headers in the packet, not in the metadata
      (aka TCP_SKB_CB(skb)->tcp_flags)
      
      The fast path in tcp_rcv_established() is not supposed to
      handle a FIN flag (it does not call tcp_fin())
      
      Therefore we need to make sure to propagate the FIN flag,
      so that the coalesced packet does not go through the fast path,
      the same than a GRO packet carrying a FIN flag.
      
      While we are at it, make sure we do not coalesce packets with
      RST or SYN, or if they do not have ACK set.
      
      Many thanks to Richard and Bruno for pinpointing the bad commit,
      and to Richard for providing a first version of the fix.
      
      Fixes: 4f693b55 ("tcp: implement coalescing on backlog queue")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: Richard Purdie's avatarRichard Purdie <richard.purdie@linuxfoundation.org>
      Reported-by: 's avatarBruno Prémont <bonbons@sysophe.eu>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b58d12d3
    • David Ahern's avatar
      selftests: fib_rule_tests: Fix icmp proto with ipv6 · 4d5aaae5
      David Ahern authored
      [ Upstream commit 15d55bae ]
      
      A recent commit returns an error if icmp is used as the ip-proto for
      IPv6 fib rules. Update fib_rule_tests to send ipv6-icmp instead of icmp.
      
      Fixes: 5e1a99ea ("ipv4: Add ICMPv6 support when parse route ipproto")
      Signed-off-by: 's avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d5aaae5
    • Willem de Bruijn's avatar
      packet: in recvmsg msg_name return at least sizeof sockaddr_ll · 3362ece2
      Willem de Bruijn authored
      [ Upstream commit b2cf86e1 ]
      
      Packet send checks that msg_name is at least sizeof sockaddr_ll.
      Packet recv must return at least this length, so that its output
      can be passed unmodified to packet send.
      
      This ceased to be true since adding support for lladdr longer than
      sll_addr. Since, the return value uses true address length.
      
      Always return at least sizeof sockaddr_ll, even if address length
      is shorter. Zero the padding bytes.
      
      Change v1->v2: do not overwrite zeroed padding again. use copy_len.
      
      Fixes: 0fb375fb ("[AF_PACKET]: Allow for > 8 byte hardware addresses.")
      Suggested-by: 's avatarDavid Laight <David.Laight@aculab.com>
      Signed-off-by: 's avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3362ece2
    • Willem de Bruijn's avatar
      packet: validate msg_namelen in send directly · 3a0701b8
      Willem de Bruijn authored
      [ Upstream commit 486efdc8 ]
      
      Packet sockets in datagram mode take a destination address. Verify its
      length before passing to dev_hard_header.
      
      Prior to 2.6.14-rc3, the send code ignored sll_halen. This is
      established behavior. Directly compare msg_namelen to dev->addr_len.
      
      Change v1->v2: initialize addr in all paths
      
      Fixes: 6b8d95f1 ("packet: validate address length if non-zero")
      Suggested-by: 's avatarDavid Laight <David.Laight@aculab.com>
      Signed-off-by: 's avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a0701b8
    • Hangbin Liu's avatar
      selftests: fib_rule_tests: print the result and return 1 if any tests failed · 02694885
      Hangbin Liu authored
      [ Upstream commit f68d7c44 ]
      
      Fixes: 65b2b493 ("selftests: net: initial fib rule tests")
      Signed-off-by: Hangbin Liu's avatarHangbin Liu <liuhangbin@gmail.com>
      Reviewed-by: 's avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02694885
    • Xin Long's avatar
      sctp: avoid running the sctp state machine recursively · 484d404f
      Xin Long authored
      [ Upstream commit fbd01973 ]
      
      Ying triggered a call trace when doing an asconf testing:
      
        BUG: scheduling while atomic: swapper/12/0/0x10000100
        Call Trace:
         <IRQ>  [<ffffffffa4375904>] dump_stack+0x19/0x1b
         [<ffffffffa436fcaf>] __schedule_bug+0x64/0x72
         [<ffffffffa437b93a>] __schedule+0x9ba/0xa00
         [<ffffffffa3cd5326>] __cond_resched+0x26/0x30
         [<ffffffffa437bc4a>] _cond_resched+0x3a/0x50
         [<ffffffffa3e22be8>] kmem_cache_alloc_node+0x38/0x200
         [<ffffffffa423512d>] __alloc_skb+0x5d/0x2d0
         [<ffffffffc0995320>] sctp_packet_transmit+0x610/0xa20 [sctp]
         [<ffffffffc098510e>] sctp_outq_flush+0x2ce/0xc00 [sctp]
         [<ffffffffc098646c>] sctp_outq_uncork+0x1c/0x20 [sctp]
         [<ffffffffc0977338>] sctp_cmd_interpreter.isra.22+0xc8/0x1460 [sctp]
         [<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
         [<ffffffffc099443d>] sctp_primitive_ASCONF+0x3d/0x50 [sctp]
         [<ffffffffc0977384>] sctp_cmd_interpreter.isra.22+0x114/0x1460 [sctp]
         [<ffffffffc0976ad1>] sctp_do_sm+0xe1/0x350 [sctp]
         [<ffffffffc097b3a4>] sctp_assoc_bh_rcv+0xf4/0x1b0 [sctp]
         [<ffffffffc09840f1>] sctp_inq_push+0x51/0x70 [sctp]
         [<ffffffffc099732b>] sctp_rcv+0xa8b/0xbd0 [sctp]
      
      As it shows, the first sctp_do_sm() running under atomic context (NET_RX
      softirq) invoked sctp_primitive_ASCONF() that uses GFP_KERNEL flag later,
      and this flag is supposed to be used in non-atomic context only. Besides,
      sctp_do_sm() was called recursively, which is not expected.
      
      Vlad tried to fix this recursive call in Commit c0786693 ("sctp: Fix
      oops when sending queued ASCONF chunks") by introducing a new command
      SCTP_CMD_SEND_NEXT_ASCONF. But it didn't work as this command is still
      used in the first sctp_do_sm() call, and sctp_primitive_ASCONF() will
      be called in this command again.
      
      To avoid calling sctp_do_sm() recursively, we send the next queued ASCONF
      not by sctp_primitive_ASCONF(), but by sctp_sf_do_prm_asconf() in the 1st
      sctp_do_sm() directly.
      Reported-by: 's avatarYing Xu <yinxu@redhat.com>
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      484d404f
    • David Howells's avatar
      rxrpc: Fix net namespace cleanup · f8970584
      David Howells authored
      [ Upstream commit b1302342 ]
      
      In rxrpc_destroy_all_calls(), there are two phases: (1) make sure the
      ->calls list is empty, emitting error messages if not, and (2) wait for the
      RCU cleanup to happen on outstanding calls (ie. ->nr_calls becomes 0).
      
      To avoid taking the call_lock, the function prechecks ->calls and if empty,
      it returns to avoid taking the lock - this is wrong, however: it still
      needs to go and do the second phase and wait for ->nr_calls to become 0.
      
      Without this, the rxrpc_net struct may get deallocated before we get to the
      RCU cleanup for the last calls.  This can lead to:
      
        Slab corruption (Not tainted): kmalloc-16k start=ffff88802b178000, len=16384
        050: 6b 6b 6b 6b 6b 6b 6b 6b 61 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkakkkkkkk
      
      Note the "61" at offset 0x58.  This corresponds to the ->nr_calls member of
      struct rxrpc_net (which is >9k in size, and thus allocated out of the 16k
      slab).
      
      Fix this by flipping the condition on the if-statement, putting the locked
      section inside the if-body and dropping the return from there.  The
      function will then always go on to wait for the RCU cleanup on outstanding
      calls.
      
      Fixes: 2baec2c3 ("rxrpc: Support network namespacing")
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8970584
    • Jakub Kicinski's avatar
      net/tls: avoid NULL pointer deref on nskb->sk in fallback · 90cb17d3
      Jakub Kicinski authored
      [ Upstream commit 2dcb0033 ]
      
      update_chksum() accesses nskb->sk before it has been set
      by complete_skb(), move the init up.
      
      Fixes: e8f69799 ("net/tls: Add generic NIC offload infrastructure")
      Signed-off-by: 's avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: 's avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90cb17d3
    • Andrew Lunn's avatar
      net: phy: marvell: Fix buffer overrun with stats counters · 52c89e45
      Andrew Lunn authored
      [ Upstream commit fdfdf867 ]
      
      marvell_get_sset_count() returns how many statistics counters there
      are. If the PHY supports fibre, there are 3, otherwise two.
      
      marvell_get_strings() does not make this distinction, and always
      returns 3 strings. This then often results in writing past the end
      of the buffer for the strings.
      
      Fixes: 2170fef7 ("Marvell phy: add field to get errors from fiber link.")
      Signed-off-by: 's avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: 's avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52c89e45
    • Dan Carpenter's avatar
      net: dsa: bcm_sf2: fix buffer overflow doing set_rxnfc · 801038cc
      Dan Carpenter authored
      [ Upstream commit f949a12f ]
      
      The "fs->location" is a u32 that comes from the user in ethtool_set_rxnfc().
      We can't pass unclamped values to test_bit() or it results in an out of
      bounds access beyond the end of the bitmap.
      
      Fixes: 7318166c ("net: dsa: bcm_sf2: Add support for ethtool::rxnfc")
      Signed-off-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      801038cc
    • Eric Dumazet's avatar
      l2tp: use rcu_dereference_sk_user_data() in l2tp_udp_encap_recv() · 31f4cb27
      Eric Dumazet authored
      [ Upstream commit c1c47721 ]
      
      Canonical way to fetch sk_user_data from an encap_rcv() handler called
      from UDP stack in rcu protected section is to use rcu_dereference_sk_user_data(),
      otherwise compiler might read it multiple times.
      
      Fixes: d00fa9ad ("il2tp: fix races with tunnel socket close")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: James Chapman <jchapman@katalix.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31f4cb27
    • Eric Dumazet's avatar
      l2ip: fix possible use-after-free · f86adc57
      Eric Dumazet authored
      [ Upstream commit a622b400 ]
      
      Before taking a refcount on a rcu protected structure,
      we need to make sure the refcount is not zero.
      
      syzbot reported :
      
      refcount_t: increment on 0; use-after-free.
      WARNING: CPU: 1 PID: 23533 at lib/refcount.c:156 refcount_inc_checked lib/refcount.c:156 [inline]
      WARNING: CPU: 1 PID: 23533 at lib/refcount.c:156 refcount_inc_checked+0x61/0x70 lib/refcount.c:154
      Kernel panic - not syncing: panic_on_warn set ...
      CPU: 1 PID: 23533 Comm: syz-executor.2 Not tainted 5.1.0-rc7+ #93
      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+0x172/0x1f0 lib/dump_stack.c:113
       panic+0x2cb/0x65c kernel/panic.c:214
       __warn.cold+0x20/0x45 kernel/panic.c:571
       report_bug+0x263/0x2b0 lib/bug.c:186
       fixup_bug arch/x86/kernel/traps.c:179 [inline]
       fixup_bug arch/x86/kernel/traps.c:174 [inline]
       do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
       do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
       invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
      RIP: 0010:refcount_inc_checked lib/refcount.c:156 [inline]
      RIP: 0010:refcount_inc_checked+0x61/0x70 lib/refcount.c:154
      Code: 1d 98 2b 2a 06 31 ff 89 de e8 db 2c 40 fe 84 db 75 dd e8 92 2b 40 fe 48 c7 c7 20 7a a1 87 c6 05 78 2b 2a 06 01 e8 7d d9 12 fe <0f> 0b eb c1 90 90 90 90 90 90 90 90 90 90 90 55 48 89 e5 41 57 41
      RSP: 0018:ffff888069f0fba8 EFLAGS: 00010286
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 000000000000f353 RSI: ffffffff815afcb6 RDI: ffffed100d3e1f67
      RBP: ffff888069f0fbb8 R08: ffff88809b1845c0 R09: ffffed1015d23ef1
      R10: ffffed1015d23ef0 R11: ffff8880ae91f787 R12: ffff8880a8f26968
      R13: 0000000000000004 R14: dffffc0000000000 R15: ffff8880a49a6440
       l2tp_tunnel_inc_refcount net/l2tp/l2tp_core.h:240 [inline]
       l2tp_tunnel_get+0x250/0x580 net/l2tp/l2tp_core.c:173
       pppol2tp_connect+0xc00/0x1c70 net/l2tp/l2tp_ppp.c:702
       __sys_connect+0x266/0x330 net/socket.c:1808
       __do_sys_connect net/socket.c:1819 [inline]
       __se_sys_connect net/socket.c:1816 [inline]
       __x64_sys_connect+0x73/0xb0 net/socket.c:1816
      
      Fixes: 54652eb1 ("l2tp: hold tunnel while looking up sessions in l2tp_netlink")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Guillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f86adc57
    • Willem de Bruijn's avatar
      ipv6: invert flowlabel sharing check in process and user mode · d1fa4f87
      Willem de Bruijn authored
      [ Upstream commit 95c16925 ]
      
      A request for a flowlabel fails in process or user exclusive mode must
      fail if the caller pid or uid does not match. Invert the test.
      
      Previously, the test was unsafe wrt PID recycling, but indeed tested
      for inequality: fl1->owner != fl->owner
      
      Fixes: 4f82f457 ("net ip6 flowlabel: Make owner a union of struct pid* and kuid_t")
      Signed-off-by: 's avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1fa4f87
    • Eric Dumazet's avatar
      ipv6/flowlabel: wait rcu grace period before put_pid() · 787a77cc
      Eric Dumazet authored
      [ Upstream commit 6c0afef5 ]
      
      syzbot was able to catch a use-after-free read in pid_nr_ns() [1]
      
      ip6fl_seq_show() seems to use RCU protection, dereferencing fl->owner.pid
      but fl_free() releases fl->owner.pid before rcu grace period is started.
      
      [1]
      
      BUG: KASAN: use-after-free in pid_nr_ns+0x128/0x140 kernel/pid.c:407
      Read of size 4 at addr ffff888094012a04 by task syz-executor.0/18087
      
      CPU: 0 PID: 18087 Comm: syz-executor.0 Not tainted 5.1.0-rc6+ #89
      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+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       __asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:131
       pid_nr_ns+0x128/0x140 kernel/pid.c:407
       ip6fl_seq_show+0x2f8/0x4f0 net/ipv6/ip6_flowlabel.c:794
       seq_read+0xad3/0x1130 fs/seq_file.c:268
       proc_reg_read+0x1fe/0x2c0 fs/proc/inode.c:227
       do_loop_readv_writev fs/read_write.c:701 [inline]
       do_loop_readv_writev fs/read_write.c:688 [inline]
       do_iter_read+0x4a9/0x660 fs/read_write.c:922
       vfs_readv+0xf0/0x160 fs/read_write.c:984
       kernel_readv fs/splice.c:358 [inline]
       default_file_splice_read+0x475/0x890 fs/splice.c:413
       do_splice_to+0x12a/0x190 fs/splice.c:876
       splice_direct_to_actor+0x2d2/0x970 fs/splice.c:953
       do_splice_direct+0x1da/0x2a0 fs/splice.c:1062
       do_sendfile+0x597/0xd00 fs/read_write.c:1443
       __do_sys_sendfile64 fs/read_write.c:1498 [inline]
       __se_sys_sendfile64 fs/read_write.c:1490 [inline]
       __x64_sys_sendfile64+0x15a/0x220 fs/read_write.c:1490
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x458da9
      Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f300d24bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
      RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 0000000000458da9
      RDX: 00000000200000c0 RSI: 0000000000000008 RDI: 0000000000000007
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 000000000000005a R11: 0000000000000246 R12: 00007f300d24c6d4
      R13: 00000000004c5fa3 R14: 00000000004da748 R15: 00000000ffffffff
      
      Allocated by task 17543:
       save_stack+0x45/0xd0 mm/kasan/common.c:75
       set_track mm/kasan/common.c:87 [inline]
       __kasan_kmalloc mm/kasan/common.c:497 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470
       kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:505
       slab_post_alloc_hook mm/slab.h:437 [inline]
       slab_alloc mm/slab.c:3393 [inline]
       kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3555
       alloc_pid+0x55/0x8f0 kernel/pid.c:168
       copy_process.part.0+0x3b08/0x7980 kernel/fork.c:1932
       copy_process kernel/fork.c:1709 [inline]
       _do_fork+0x257/0xfd0 kernel/fork.c:2226
       __do_sys_clone kernel/fork.c:2333 [inline]
       __se_sys_clone kernel/fork.c:2327 [inline]
       __x64_sys_clone+0xbf/0x150 kernel/fork.c:2327
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 7789:
       save_stack+0x45/0xd0 mm/kasan/common.c:75
       set_track mm/kasan/common.c:87 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:459
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:467
       __cache_free mm/slab.c:3499 [inline]
       kmem_cache_free+0x86/0x260 mm/slab.c:3765
       put_pid.part.0+0x111/0x150 kernel/pid.c:111
       put_pid+0x20/0x30 kernel/pid.c:105
       fl_free+0xbe/0xe0 net/ipv6/ip6_flowlabel.c:102
       ip6_fl_gc+0x295/0x3e0 net/ipv6/ip6_flowlabel.c:152
       call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
       expire_timers kernel/time/timer.c:1362 [inline]
       __run_timers kernel/time/timer.c:1681 [inline]
       __run_timers kernel/time/timer.c:1649 [inline]
       run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
       __do_softirq+0x266/0x95a kernel/softirq.c:293
      
      The buggy address belongs to the object at ffff888094012a00
       which belongs to the cache pid_2 of size 88
      The buggy address is located 4 bytes inside of
       88-byte region [ffff888094012a00, ffff888094012a58)
      The buggy address belongs to the page:
      page:ffffea0002500480 count:1 mapcount:0 mapping:ffff88809a483080 index:0xffff888094012980
      flags: 0x1fffc0000000200(slab)
      raw: 01fffc0000000200 ffffea00018a3508 ffffea0002524a88 ffff88809a483080
      raw: ffff888094012980 ffff888094012000 000000010000001b 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888094012900: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
       ffff888094012980: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
      >ffff888094012a00: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
                         ^
       ffff888094012a80: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
       ffff888094012b00: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
      
      Fixes: 4f82f457 ("net ip6 flowlabel: Make owner a union of struct pid * and kuid_t")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      787a77cc
    • Eric Dumazet's avatar
      ipv6: fix races in ip6_dst_destroy() · d0aa7946
      Eric Dumazet authored
      [ Upstream commit 0e233874 ]
      
      We had many syzbot reports that seem to be caused by use-after-free
      of struct fib6_info.
      
      ip6_dst_destroy(), fib6_drop_pcpu_from() and rt6_remove_exception()
      are writers vs rt->from, and use non consistent synchronization among
      themselves.
      
      Switching to xchg() will solve the issues with no possible
      lockdep issues.
      
      BUG: KASAN: user-memory-access in atomic_dec_and_test include/asm-generic/atomic-instrumented.h:747 [inline]
      BUG: KASAN: user-memory-access in fib6_info_release include/net/ip6_fib.h:294 [inline]
      BUG: KASAN: user-memory-access in fib6_info_release include/net/ip6_fib.h:292 [inline]
      BUG: KASAN: user-memory-access in fib6_drop_pcpu_from net/ipv6/ip6_fib.c:927 [inline]
      BUG: KASAN: user-memory-access in fib6_purge_rt+0x4f6/0x670 net/ipv6/ip6_fib.c:960
      Write of size 4 at addr 0000000000ffffb4 by task syz-executor.1/7649
      
      CPU: 0 PID: 7649 Comm: syz-executor.1 Not tainted 5.1.0-rc6+ #183
      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+0x172/0x1f0 lib/dump_stack.c:113
       kasan_report.cold+0x5/0x40 mm/kasan/report.c:321
       check_memory_region_inline mm/kasan/generic.c:185 [inline]
       check_memory_region+0x123/0x190 mm/kasan/generic.c:191
       kasan_check_write+0x14/0x20 mm/kasan/common.c:108
       atomic_dec_and_test include/asm-generic/atomic-instrumented.h:747 [inline]
       fib6_info_release include/net/ip6_fib.h:294 [inline]
       fib6_info_release include/net/ip6_fib.h:292 [inline]
       fib6_drop_pcpu_from net/ipv6/ip6_fib.c:927 [inline]
       fib6_purge_rt+0x4f6/0x670 net/ipv6/ip6_fib.c:960
       fib6_del_route net/ipv6/ip6_fib.c:1813 [inline]
       fib6_del+0xac2/0x10a0 net/ipv6/ip6_fib.c:1844
       fib6_clean_node+0x3a8/0x590 net/ipv6/ip6_fib.c:2006
       fib6_walk_continue+0x495/0x900 net/ipv6/ip6_fib.c:1928
       fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:1976
       fib6_clean_tree+0xe0/0x120 net/ipv6/ip6_fib.c:2055
       __fib6_clean_all+0x118/0x2a0 net/ipv6/ip6_fib.c:2071
       fib6_clean_all+0x2b/0x40 net/ipv6/ip6_fib.c:2082
       rt6_sync_down_dev+0x134/0x150 net/ipv6/route.c:4057
       rt6_disable_ip+0x27/0x5f0 net/ipv6/route.c:4062
       addrconf_ifdown+0xa2/0x1220 net/ipv6/addrconf.c:3705
       addrconf_notify+0x19a/0x2260 net/ipv6/addrconf.c:3630
       notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1753
       call_netdevice_notifiers_extack net/core/dev.c:1765 [inline]
       call_netdevice_notifiers net/core/dev.c:1779 [inline]
       dev_close_many+0x33f/0x6f0 net/core/dev.c:1522
       rollback_registered_many+0x43b/0xfd0 net/core/dev.c:8177
       rollback_registered+0x109/0x1d0 net/core/dev.c:8242
       unregister_netdevice_queue net/core/dev.c:9289 [inline]
       unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9282
       unregister_netdevice include/linux/netdevice.h:2658 [inline]
       __tun_detach+0xd5b/0x1000 drivers/net/tun.c:727
       tun_detach drivers/net/tun.c:744 [inline]
       tun_chr_close+0xe0/0x180 drivers/net/tun.c:3443
       __fput+0x2e5/0x8d0 fs/file_table.c:278
       ____fput+0x16/0x20 fs/file_table.c:309
       task_work_run+0x14a/0x1c0 kernel/task_work.c:113
       exit_task_work include/linux/task_work.h:22 [inline]
       do_exit+0x90a/0x2fa0 kernel/exit.c:876
       do_group_exit+0x135/0x370 kernel/exit.c:980
       __do_sys_exit_group kernel/exit.c:991 [inline]
       __se_sys_exit_group kernel/exit.c:989 [inline]
       __x64_sys_exit_group+0x44/0x50 kernel/exit.c:989
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x458da9
      Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffeafc2a6a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
      RAX: ffffffffffffffda RBX: 000000000000001c RCX: 0000000000458da9
      RDX: 0000000000412a80 RSI: 0000000000a54ef0 RDI: 0000000000000043
      RBP: 00000000004be552 R08: 000000000000000c R09: 000000000004c0d1
      R10: 0000000002341940 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00007ffeafc2a7f0 R14: 000000000004c065 R15: 00007ffeafc2a800
      
      Fixes: a68886a6 ("net/ipv6: Make from in rt6_info rcu protected")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: 's avatarDavid Ahern <dsahern@gmail.com>
      Acked-by: 's avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: 's avatarWei Wang <weiwan@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0aa7946
    • Martin KaFai Lau's avatar
      ipv6: A few fixes on dereferencing rt->from · c61a4beb
      Martin KaFai Lau authored
      [ Upstream commit 886b7a50 ]
      
      It is a followup after the fix in
      commit 9c69a132 ("route: Avoid crash from dereferencing NULL rt->from")
      
      rt6_do_redirect():
      1. NULL checking is needed on rt->from because a parallel
         fib6_info delete could happen that sets rt->from to NULL.
         (e.g. rt6_remove_exception() and fib6_drop_pcpu_from()).
      
      2. fib6_info_hold() is not enough.  Same reason as (1).
         Meaning, holding dst->__refcnt cannot ensure
         rt->from is not NULL or rt->from->fib6_ref is not 0.
      
         Instead of using fib6_info_hold_safe() which ip6_rt_cache_alloc()
         is already doing, this patch chooses to extend the rcu section
         to keep "from" dereference-able after checking for NULL.
      
      inet6_rtm_getroute():
      1. NULL checking is also needed on rt->from for a similar reason.
         Note that inet6_rtm_getroute() is using RTNL_FLAG_DOIT_UNLOCKED.
      
      Fixes: a68886a6 ("net/ipv6: Make from in rt6_info rcu protected")
      Signed-off-by: 's avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: 's avatarWei Wang <weiwan@google.com>
      Reviewed-by: 's avatarDavid Ahern <dsahern@gmail.com>
      Reviewed-by: 's avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c61a4beb
    • Shmulik Ladkani's avatar
      ipv4: ip_do_fragment: Preserve skb_iif during fragmentation · 5a06ba5e
      Shmulik Ladkani authored
      [ Upstream commit d2f0c961 ]
      
      Previously, during fragmentation after forwarding, skb->skb_iif isn't
      preserved, i.e. 'ip_copy_metadata' does not copy skb_iif from given
      'from' skb.
      
      As a result, ip_do_fragment's creates fragments with zero skb_iif,
      leading to inconsistent behavior.
      
      Assume for example an eBPF program attached at tc egress (post
      forwarding) that examines __sk_buff->ingress_ifindex:
       - the correct iif is observed if forwarding path does not involve
         fragmentation/refragmentation
       - a bogus iif is observed if forwarding path involves
         fragmentation/refragmentatiom
      
      Fix, by preserving skb_iif during 'ip_copy_metadata'.
      Signed-off-by: 's avatarShmulik Ladkani <shmulik.ladkani@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a06ba5e
  2. 04 May, 2019 6 commits
    • Oleksandr Natalenko's avatar
      Merge branch 'fixes-5.0' into pf-5.0 · 27135522
      Oleksandr Natalenko authored
      27135522
    • Eric Dumazet's avatar
      udp: fix GRO packet of death · 73908d22
      Eric Dumazet authored
      syzbot was able to crash host by sending UDP packets with a 0 payload.
      
      TCP does not have this issue since we do not aggregate packets without
      payload.
      
      Since dev_gro_receive() sets gso_size based on skb_gro_len(skb)
      it seems not worth trying to cope with padded packets.
      
      BUG: KASAN: slab-out-of-bounds in skb_gro_receive+0xf5f/0x10e0 net/core/skbuff.c:3826
      Read of size 16 at addr ffff88808893fff0 by task syz-executor612/7889
      
      CPU: 0 PID: 7889 Comm: syz-executor612 Not tainted 5.1.0-rc7+ #96
      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+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       __asan_report_load16_noabort+0x14/0x20 mm/kasan/generic_report.c:133
       skb_gro_receive+0xf5f/0x10e0 net/core/skbuff.c:3826
       udp_gro_receive_segment net/ipv4/udp_offload.c:382 [inline]
       call_gro_receive include/linux/netdevice.h:2349 [inline]
       udp_gro_receive+0xb61/0xfd0 net/ipv4/udp_offload.c:414
       udp4_gro_receive+0x763/0xeb0 net/ipv4/udp_offload.c:478
       inet_gro_receive+0xe72/0x1110 net/ipv4/af_inet.c:1510
       dev_gro_receive+0x1cd0/0x23c0 net/core/dev.c:5581
       napi_gro_frags+0x36b/0xd10 net/core/dev.c:5843
       tun_get_user+0x2f24/0x3fb0 drivers/net/tun.c:1981
       tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2027
       call_write_iter include/linux/fs.h:1866 [inline]
       do_iter_readv_writev+0x5e1/0x8e0 fs/read_write.c:681
       do_iter_write fs/read_write.c:957 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:938
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1002
       do_writev+0x15e/0x370 fs/read_write.c:1037
       __do_sys_writev fs/read_write.c:1110 [inline]
       __se_sys_writev fs/read_write.c:1107 [inline]
       __x64_sys_writev+0x75/0xb0 fs/read_write.c:1107
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x441cc0
      Code: 05 48 3d 01 f0 ff ff 0f 83 9d 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 3d 51 93 29 00 00 75 14 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 74 09 fc ff c3 48 83 ec 08 e8 ba 2b 00 00
      RSP: 002b:00007ffe8c716118 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
      RAX: ffffffffffffffda RBX: 00007ffe8c716150 RCX: 0000000000441cc0
      RDX: 0000000000000001 RSI: 00007ffe8c716170 RDI: 00000000000000f0
      RBP: 0000000000000000 R08: 000000000000ffff R09: 0000000000a64668
      R10: 0000000020000040 R11: 0000000000000246 R12: 000000000000c2d9
      R13: 0000000000402b50 R14: 0000000000000000 R15: 0000000000000000
      
      Allocated by task 5143:
       save_stack+0x45/0xd0 mm/kasan/common.c:75
       set_track mm/kasan/common.c:87 [inline]
       __kasan_kmalloc mm/kasan/common.c:497 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470
       kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:505
       slab_post_alloc_hook mm/slab.h:437 [inline]
       slab_alloc mm/slab.c:3393 [inline]
       kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3555
       mm_alloc+0x1d/0xd0 kernel/fork.c:1030
       bprm_mm_init fs/exec.c:363 [inline]
       __do_execve_file.isra.0+0xaa3/0x23f0 fs/exec.c:1791
       do_execveat_common fs/exec.c:1865 [inline]
       do_execve fs/exec.c:1882 [inline]
       __do_sys_execve fs/exec.c:1958 [inline]
       __se_sys_execve fs/exec.c:1953 [inline]
       __x64_sys_execve+0x8f/0xc0 fs/exec.c:1953
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 5351:
       save_stack+0x45/0xd0 mm/kasan/common.c:75
       set_track mm/kasan/common.c:87 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:459
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:467
       __cache_free mm/slab.c:3499 [inline]
       kmem_cache_free+0x86/0x260 mm/slab.c:3765
       __mmdrop+0x238/0x320 kernel/fork.c:677
       mmdrop include/linux/sched/mm.h:49 [inline]
       finish_task_switch+0x47b/0x780 kernel/sched/core.c:2746
       context_switch kernel/sched/core.c:2880 [inline]
       __schedule+0x81b/0x1cc0 kernel/sched/core.c:3518
       preempt_schedule_irq+0xb5/0x140 kernel/sched/core.c:3745
       retint_kernel+0x1b/0x2d
       arch_local_irq_restore arch/x86/include/asm/paravirt.h:767 [inline]
       kmem_cache_free+0xab/0x260 mm/slab.c:3766
       anon_vma_chain_free mm/rmap.c:134 [inline]
       unlink_anon_vmas+0x2ba/0x870 mm/rmap.c:401
       free_pgtables+0x1af/0x2f0 mm/memory.c:394
       exit_mmap+0x2d1/0x530 mm/mmap.c:3144
       __mmput kernel/fork.c:1046 [inline]
       mmput+0x15f/0x4c0 kernel/fork.c:1067
       exec_mmap fs/exec.c:1046 [inline]
       flush_old_exec+0x8d9/0x1c20 fs/exec.c:1279
       load_elf_binary+0x9bc/0x53f0 fs/binfmt_elf.c:864
       search_binary_handler fs/exec.c:1656 [inline]
       search_binary_handler+0x17f/0x570 fs/exec.c:1634
       exec_binprm fs/exec.c:1698 [inline]
       __do_execve_file.isra.0+0x1394/0x23f0 fs/exec.c:1818
       do_execveat_common fs/exec.c:1865 [inline]
       do_execve fs/exec.c:1882 [inline]
       __do_sys_execve fs/exec.c:1958 [inline]
       __se_sys_execve fs/exec.c:1953 [inline]
       __x64_sys_execve+0x8f/0xc0 fs/exec.c:1953
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff88808893f7c0
       which belongs to the cache mm_struct of size 1496
      The buggy address is located 600 bytes to the right of
       1496-byte region [ffff88808893f7c0, ffff88808893fd98)
      The buggy address belongs to the page:
      page:ffffea0002224f80 count:1 mapcount:0 mapping:ffff88821bc40ac0 index:0xffff88808893f7c0 compound_mapcount: 0
      flags: 0x1fffc0000010200(slab|head)
      raw: 01fffc0000010200 ffffea00025b4f08 ffffea00027b9d08 ffff88821bc40ac0
      raw: ffff88808893f7c0 ffff88808893e440 0000000100000001 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88808893fe80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff88808893ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff88808893ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                   ^
       ffff888088940000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff888088940080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Fixes: e20cf8d3 ("udp: implement GRO for plain UDP sockets.")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      73908d22
    • Paolo Abeni's avatar
      udp: fix GRO reception in case of length mismatch · 874c73d0
      Paolo Abeni authored
      Currently, the UDP GRO code path does bad things on some edge
      conditions - Aggregation can happen even on packet with different
      lengths.
      
      Fix the above by rewriting the 'complete' condition for GRO
      packets. While at it, note explicitly that we allow merging the
      first packet per burst below gso_size.
      Reported-by: 's avatarSean Tong <seantong114@gmail.com>
      Fixes: e20cf8d3 ("udp: implement GRO for plain UDP sockets.")
      Signed-off-by: 's avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      874c73d0
    • Oleksandr Natalenko's avatar
      Merge tag 'v5.0.12' into pf-5.0 · 3625eb7f
      Oleksandr Natalenko authored
      This is the 5.0.12 stable release
      3625eb7f
    • Oleksandr Natalenko's avatar
      e8e61464
    • Greg Kroah-Hartman's avatar
      Linux 5.0.12 · 6006d5b0
      Greg Kroah-Hartman authored
      6006d5b0