1. 01 May, 2019 9 commits
    • Shmulik Ladkani's avatar
      ipv4: ip_do_fragment: Preserve skb_iif during fragmentation · d2f0c961
      Shmulik Ladkani authored
      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: default avatarShmulik Ladkani <shmulik.ladkani@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d2f0c961
    • Jakub Kicinski's avatar
      net/tls: avoid NULL pointer deref on nskb->sk in fallback · 2dcb0033
      Jakub Kicinski authored
      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: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2dcb0033
    • David Ahern's avatar
      selftests: fib_rule_tests: Fix icmp proto with ipv6 · 15d55bae
      David Ahern authored
      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: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15d55bae
    • Willem de Bruijn's avatar
      packet: validate msg_namelen in send directly · 486efdc8
      Willem de Bruijn authored
      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: default avatarDavid Laight <David.Laight@aculab.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      486efdc8
    • Willem de Bruijn's avatar
      packet: in recvmsg msg_name return at least sizeof sockaddr_ll · b2cf86e1
      Willem de Bruijn authored
      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: default avatarDavid Laight <David.Laight@aculab.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b2cf86e1
    • Xin Long's avatar
      sctp: avoid running the sctp state machine recursively · fbd01973
      Xin Long authored
      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: default avatarYing Xu <yinxu@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbd01973
    • Jan Kiszka's avatar
    • Randy Dunlap's avatar
      Documentation: fix netdev-FAQ.rst markup warning · 799381e4
      Randy Dunlap authored
      Fix ReST underline warning:
      
      ./Documentation/networking/netdev-FAQ.rst:135: WARNING: Title underline too short.
      
      Q: I made changes to only a few patches in a patch series should I resend only those changed?
      --------------------------------------------------------------------------------------------
      
      Fixes: ffa91253 ("Documentation: networking: Update netdev-FAQ regarding patches")
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      799381e4
    • Eric Dumazet's avatar
      ipv6: fix races in ip6_dst_destroy() · 0e233874
      Eric Dumazet authored
      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: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarWei Wang <weiwan@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0e233874
  2. 30 Apr, 2019 9 commits
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2019-04-30' of... · 34259977
      David S. Miller authored
      Merge tag 'wireless-drivers-for-davem-2019-04-30' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 5.1
      
      Third set of fixes for 5.1.
      
      iwlwifi
      
      * fix an oops when creating debugfs entries
      
      * fix bug when trying to capture debugging info while in rfkill
      
      * prevent potential uninitialized memory dumps into debugging logs
      
      * fix some initialization parameters for AX210 devices
      
      * fix an oops with non-MSIX devices
      
      * fix an oops when we receive a packet with bogus lengths
      
      * fix a bug that prevented 5350 devices from working
      
      * fix a small merge damage from the previous series
      
      mwifiex
      
      * fig regression with resume on SDIO
      
      ath10k
      
      * fix locking problem with crashdump
      
      * fix warnings during suspend and resume
      
      Also note that this pull conflicts with net-next. And I want to emphasie
      that it's really net-next, so when you pull this to net tree it should
      go without conflicts. Stephen reported the conflict here:
      
      https://lkml.kernel.org/r/20190429115338.5decb50b@canb.auug.org.au
      
      In iwlwifi oddly commit 154d4899 adds the IS_ERR_OR_NULL() in
      wireless-drivers but commit c9af7528 removes the whole check in
      wireless-drivers-next. The fix is easy, just drop the whole check for
      mvmvif->dbgfs_dir in iwlwifi/mvm/debugfs-vif.c, it's unneeded anyway.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34259977
    • Eric Dumazet's avatar
      l2ip: fix possible use-after-free · a622b400
      Eric Dumazet authored
      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: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Guillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a622b400
    • YueHaibing's avatar
      appletalk: Set error code if register_snap_client failed · c93ad133
      YueHaibing authored
      If register_snap_client fails in atalk_init,
      error code should be set, otherwise it will
      triggers NULL pointer dereference while unloading
      module.
      
      Fixes: 9804501f ("appletalk: Fix potential NULL pointer dereference in unregister_snap_client")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c93ad133
    • Dan Carpenter's avatar
      net: dsa: bcm_sf2: fix buffer overflow doing set_rxnfc · f949a12f
      Dan Carpenter authored
      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: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f949a12f
    • David Howells's avatar
      rxrpc: Fix net namespace cleanup · b1302342
      David Howells authored
      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: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1302342
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · b145745f
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2019-04-30
      
      1) Fix an out-of-bound array accesses in __xfrm_policy_unlink.
         From YueHaibing.
      
      2) Reset the secpath on failure in the ESP GRO handlers
         to avoid dereferencing an invalid pointer on error.
         From Myungho Jung.
      
      3) Add and revert a patch that tried to add rcu annotations
         to netns_xfrm. From Su Yanjun.
      
      4) Wait for rcu callbacks before freeing xfrm6_tunnel_spi_kmem.
         From Su Yanjun.
      
      5) Fix forgotten vti4 ipip tunnel deregistration.
         From Jeremy Sowden:
      
      6) Remove some duplicated log messages in vti4.
         From Jeremy Sowden.
      
      7) Don't use IPSEC_PROTO_ANY when flushing states because
         this will flush only IPsec portocol speciffic states.
         IPPROTO_ROUTING states may remain in the lists when
         doing net exit. Fix this by replacing IPSEC_PROTO_ANY
         with zero. From Cong Wang.
      
      8) Add length check for UDP encapsulation to fix "Oversized IP packet"
         warnings on receive side. From Sabrina Dubroca.
      
      9) Fix xfrm interface lookup when the interface is associated to
         a vrf layer 3 master device. From Martin Willi.
      
      10) Reload header pointers after pskb_may_pull() in _decode_session4(),
          otherwise we may read from uninitialized memory.
      
      11) Update the documentation about xfrm[46]_gc_thresh, it
          is not used anymore after the flowcache removal.
          From Nicolas Dichtel.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b145745f
    • Eric Dumazet's avatar
      ipv6/flowlabel: wait rcu grace period before put_pid() · 6c0afef5
      Eric Dumazet authored
      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: default avatarEric Dumazet <edumazet@google.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c0afef5
    • Stephen Suryaputra's avatar
      vrf: Use orig netdev to count Ip6InNoRoutes and a fresh route lookup when sending dest unreach · 1d3fd8a1
      Stephen Suryaputra authored
      When there is no route to an IPv6 dest addr, skb_dst(skb) points
      to loopback dev in the case of that the IP6CB(skb)->iif is
      enslaved to a vrf. This causes Ip6InNoRoutes to be incremented on the
      loopback dev. This also causes the lookup to fail on icmpv6_send() and
      the dest unreachable to not sent and Ip6OutNoRoutes gets incremented on
      the loopback dev.
      
      To reproduce:
      * Gateway configuration:
              ip link add dev vrf_258 type vrf table 258
              ip link set dev enp0s9 master vrf_258
              ip addr add 66:1/64 dev enp0s9
              ip -6 route add unreachable default metric 8192 table 258
              sysctl -w net.ipv6.conf.all.forwarding=1
              sysctl -w net.ipv6.conf.enp0s9.forwarding=1
      * Sender configuration:
              ip addr add 66::2/64 dev enp0s9
              ip -6 route add default via 66::1
      and ping 67::1 for example from the sender.
      
      Fix this by counting on the original netdev and reset the skb dst to
      force a fresh lookup.
      
      v2: Fix typo of destination address in the repro steps.
      v3: Simplify the loopback check (per David Ahern) and use reverse
          Christmas tree format (per David Miller).
      Signed-off-by: default avatarStephen Suryaputra <ssuryaextr@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Tested-by: default avatarDavid Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d3fd8a1
    • Eric Dumazet's avatar
      tcp: add sanity tests in tcp_add_backlog() · ca2fe295
      Eric Dumazet authored
      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: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarRichard Purdie <richard.purdie@linuxfoundation.org>
      Reported-by: default avatarBruno Prémont <bonbons@sysophe.eu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ca2fe295
  3. 29 Apr, 2019 6 commits
  4. 28 Apr, 2019 8 commits
    • Kalle Valo's avatar
      Merge tag 'iwlwifi-for-kalle-2019-04-28' of... · 5c403533
      Kalle Valo authored
      Merge tag 'iwlwifi-for-kalle-2019-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
      
      Fourth batch of patches intended for v5.1
      
      * Fix an oops when we receive a packet with bogus lengths;
      * Fix a bug that prevented 5350 devices from working;
      * Fix a small merge damage from the previous series;
      5c403533
    • Luca Coelho's avatar
      iwlwifi: mvm: fix merge damage in iwl_mvm_vif_dbgfs_register() · d156e67d
      Luca Coelho authored
      When I rebased Greg's patch, I accidentally left the old if block that
      was already there.  Remove it.
      
      Fixes: 154d4899 ("iwlwifi: mvm: properly check debugfs dentry before using it")
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      d156e67d
    • Emmanuel Grumbach's avatar
      iwlwifi: fix driver operation for 5350 · 5c9adef9
      Emmanuel Grumbach authored
      We introduced a bug that prevented this old device from
      working. The driver would simply not be able to complete
      the INIT flow while spewing this warning:
      
       CSR addresses aren't configured
       WARNING: CPU: 0 PID: 819 at drivers/net/wireless/intel/iwlwifi/pcie/drv.c:917
       iwl_pci_probe+0x160/0x1e0 [iwlwifi]
      
      Cc: stable@vger.kernel.org # v4.18+
      Fixes: a8cbb46f ("iwlwifi: allow different csr flags for different device families")
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Fixes: c8f1b51e ("iwlwifi: allow different csr flags for different device families")
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      5c9adef9
    • Luca Coelho's avatar
      iwlwifi: mvm: check for length correctness in iwl_mvm_create_skb() · de1887c0
      Luca Coelho authored
      We don't check for the validity of the lengths in the packet received
      from the firmware.  If the MPDU length received in the rx descriptor
      is too short to contain the header length and the crypt length
      together, we may end up trying to copy a negative number of bytes
      (headlen - hdrlen < 0) which will underflow and cause us to try to
      copy a huge amount of data.  This causes oopses such as this one:
      
      BUG: unable to handle kernel paging request at ffff896be2970000
      PGD 5e201067 P4D 5e201067 PUD 5e205067 PMD 16110d063 PTE 8000000162970161
      Oops: 0003 [#1] PREEMPT SMP NOPTI
      CPU: 2 PID: 1824 Comm: irq/134-iwlwifi Not tainted 4.19.33-04308-geea41cf4930f #1
      Hardware name: [...]
      RIP: 0010:memcpy_erms+0x6/0x10
      Code: 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3
       0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe
      RSP: 0018:ffffa4630196fc60 EFLAGS: 00010287
      RAX: ffff896be2924618 RBX: ffff896bc8ecc600 RCX: 00000000fffb4610
      RDX: 00000000fffffff8 RSI: ffff896a835e2a38 RDI: ffff896be2970000
      RBP: ffffa4630196fd30 R08: ffff896bc8ecc600 R09: ffff896a83597000
      R10: ffff896bd6998400 R11: 000000000200407f R12: ffff896a83597050
      R13: 00000000fffffff8 R14: 0000000000000010 R15: ffff896a83597038
      FS:  0000000000000000(0000) GS:ffff896be8280000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffff896be2970000 CR3: 000000005dc12002 CR4: 00000000003606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       iwl_mvm_rx_mpdu_mq+0xb51/0x121b [iwlmvm]
       iwl_pcie_rx_handle+0x58c/0xa89 [iwlwifi]
       iwl_pcie_irq_rx_msix_handler+0xd9/0x12a [iwlwifi]
       irq_thread_fn+0x24/0x49
       irq_thread+0xb0/0x122
       kthread+0x138/0x140
       ret_from_fork+0x1f/0x40
      
      Fix that by checking the lengths for correctness and trigger a warning
      to show that we have received wrong data.
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      de1887c0
    • Paolo Abeni's avatar
      udp: fix GRO reception in case of length mismatch · 21f1b8a6
      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: default avatarSean Tong <seantong114@gmail.com>
      Fixes: e20cf8d3 ("udp: implement GRO for plain UDP sockets.")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21f1b8a6
    • David S. Miller's avatar
      Merge branch 'tls-data-copies' · fbef9478
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      net/tls: fix data copies in tls_device_reencrypt()
      
      This series fixes the tls_device_reencrypt() which is broken
      if record starts in the frags of the message skb.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbef9478
    • Jakub Kicinski's avatar
      net/tls: fix copy to fragments in reencrypt · eb3d38d5
      Jakub Kicinski authored
      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: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb3d38d5
    • Jakub Kicinski's avatar
      net/tls: don't copy negative amounts of data in reencrypt · 97e1caa5
      Jakub Kicinski authored
      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: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97e1caa5
  5. 27 Apr, 2019 7 commits
  6. 26 Apr, 2019 1 commit