1. 12 10月, 2019 1 次提交
    • D
      rxrpc: Fix possible NULL pointer access in ICMP handling · f0308fb0
      David Howells 提交于
      If an ICMP packet comes in on the UDP socket backing an AF_RXRPC socket as
      the UDP socket is being shut down, rxrpc_error_report() may get called to
      deal with it after sk_user_data on the UDP socket has been cleared, leading
      to a NULL pointer access when this local endpoint record gets accessed.
      
      Fix this by just returning immediately if sk_user_data was NULL.
      
      The oops looks like the following:
      
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      ...
      RIP: 0010:rxrpc_error_report+0x1bd/0x6a9
      ...
      Call Trace:
       ? sock_queue_err_skb+0xbd/0xde
       ? __udp4_lib_err+0x313/0x34d
       __udp4_lib_err+0x313/0x34d
       icmp_unreach+0x1ee/0x207
       icmp_rcv+0x25b/0x28f
       ip_protocol_deliver_rcu+0x95/0x10e
       ip_local_deliver+0xe9/0x148
       __netif_receive_skb_one_core+0x52/0x6e
       process_backlog+0xdc/0x177
       net_rx_action+0xf9/0x270
       __do_softirq+0x1b6/0x39a
       ? smpboot_register_percpu_thread+0xce/0xce
       run_ksoftirqd+0x1d/0x42
       smpboot_thread_fn+0x19e/0x1b3
       kthread+0xf1/0xf6
       ? kthread_delayed_work_timer_fn+0x83/0x83
       ret_from_fork+0x24/0x30
      
      Fixes: 17926a79 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
      Reported-by: syzbot+611164843bd48cc2190c@syzkaller.appspotmail.com
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f0308fb0
  2. 11 10月, 2019 6 次提交
  3. 10 10月, 2019 20 次提交
    • E
      net: silence KCSAN warnings about sk->sk_backlog.len reads · 70c26558
      Eric Dumazet 提交于
      sk->sk_backlog.len can be written by BH handlers, and read
      from process contexts in a lockless way.
      
      Note the write side should also use WRITE_ONCE() or a variant.
      We need some agreement about the best way to do this.
      
      syzbot reported :
      
      BUG: KCSAN: data-race in tcp_add_backlog / tcp_grow_window.isra.0
      
      write to 0xffff88812665f32c of 4 bytes by interrupt on cpu 1:
       sk_add_backlog include/net/sock.h:934 [inline]
       tcp_add_backlog+0x4a0/0xcc0 net/ipv4/tcp_ipv4.c:1737
       tcp_v4_rcv+0x1aba/0x1bf0 net/ipv4/tcp_ipv4.c:1925
       ip_protocol_deliver_rcu+0x51/0x470 net/ipv4/ip_input.c:204
       ip_local_deliver_finish+0x110/0x140 net/ipv4/ip_input.c:231
       NF_HOOK include/linux/netfilter.h:305 [inline]
       NF_HOOK include/linux/netfilter.h:299 [inline]
       ip_local_deliver+0x133/0x210 net/ipv4/ip_input.c:252
       dst_input include/net/dst.h:442 [inline]
       ip_rcv_finish+0x121/0x160 net/ipv4/ip_input.c:413
       NF_HOOK include/linux/netfilter.h:305 [inline]
       NF_HOOK include/linux/netfilter.h:299 [inline]
       ip_rcv+0x18f/0x1a0 net/ipv4/ip_input.c:523
       __netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:5004
       __netif_receive_skb+0x37/0xf0 net/core/dev.c:5118
       netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5208
       napi_skb_finish net/core/dev.c:5671 [inline]
       napi_gro_receive+0x28f/0x330 net/core/dev.c:5704
       receive_buf+0x284/0x30b0 drivers/net/virtio_net.c:1061
       virtnet_receive drivers/net/virtio_net.c:1323 [inline]
       virtnet_poll+0x436/0x7d0 drivers/net/virtio_net.c:1428
       napi_poll net/core/dev.c:6352 [inline]
       net_rx_action+0x3ae/0xa50 net/core/dev.c:6418
      
      read to 0xffff88812665f32c of 4 bytes by task 7292 on cpu 0:
       tcp_space include/net/tcp.h:1373 [inline]
       tcp_grow_window.isra.0+0x6b/0x480 net/ipv4/tcp_input.c:413
       tcp_event_data_recv+0x68f/0x990 net/ipv4/tcp_input.c:717
       tcp_rcv_established+0xbfe/0xf50 net/ipv4/tcp_input.c:5618
       tcp_v4_do_rcv+0x381/0x4e0 net/ipv4/tcp_ipv4.c:1542
       sk_backlog_rcv include/net/sock.h:945 [inline]
       __release_sock+0x135/0x1e0 net/core/sock.c:2427
       release_sock+0x61/0x160 net/core/sock.c:2943
       tcp_recvmsg+0x63b/0x1a30 net/ipv4/tcp.c:2181
       inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838
       sock_recvmsg_nosec net/socket.c:871 [inline]
       sock_recvmsg net/socket.c:889 [inline]
       sock_recvmsg+0x92/0xb0 net/socket.c:885
       sock_read_iter+0x15f/0x1e0 net/socket.c:967
       call_read_iter include/linux/fs.h:1864 [inline]
       new_sync_read+0x389/0x4f0 fs/read_write.c:414
       __vfs_read+0xb1/0xc0 fs/read_write.c:427
       vfs_read fs/read_write.c:461 [inline]
       vfs_read+0x143/0x2c0 fs/read_write.c:446
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 7292 Comm: syz-fuzzer Not tainted 5.3.0+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      70c26558
    • E
      net: annotate sk->sk_rcvlowat lockless reads · eac66402
      Eric Dumazet 提交于
      sock_rcvlowat() or int_sk_rcvlowat() might be called without the socket
      lock for example from tcp_poll().
      
      Use READ_ONCE() to document the fact that other cpus might change
      sk->sk_rcvlowat under us and avoid KCSAN splats.
      
      Use WRITE_ONCE() on write sides too.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      eac66402
    • E
      net: silence KCSAN warnings around sk_add_backlog() calls · 8265792b
      Eric Dumazet 提交于
      sk_add_backlog() callers usually read sk->sk_rcvbuf without
      owning the socket lock. This means sk_rcvbuf value can
      be changed by other cpus, and KCSAN complains.
      
      Add READ_ONCE() annotations to document the lockless nature
      of these reads.
      
      Note that writes over sk_rcvbuf should also use WRITE_ONCE(),
      but this will be done in separate patches to ease stable
      backports (if we decide this is relevant for stable trees).
      
      BUG: KCSAN: data-race in tcp_add_backlog / tcp_recvmsg
      
      write to 0xffff88812ab369f8 of 8 bytes by interrupt on cpu 1:
       __sk_add_backlog include/net/sock.h:902 [inline]
       sk_add_backlog include/net/sock.h:933 [inline]
       tcp_add_backlog+0x45a/0xcc0 net/ipv4/tcp_ipv4.c:1737
       tcp_v4_rcv+0x1aba/0x1bf0 net/ipv4/tcp_ipv4.c:1925
       ip_protocol_deliver_rcu+0x51/0x470 net/ipv4/ip_input.c:204
       ip_local_deliver_finish+0x110/0x140 net/ipv4/ip_input.c:231
       NF_HOOK include/linux/netfilter.h:305 [inline]
       NF_HOOK include/linux/netfilter.h:299 [inline]
       ip_local_deliver+0x133/0x210 net/ipv4/ip_input.c:252
       dst_input include/net/dst.h:442 [inline]
       ip_rcv_finish+0x121/0x160 net/ipv4/ip_input.c:413
       NF_HOOK include/linux/netfilter.h:305 [inline]
       NF_HOOK include/linux/netfilter.h:299 [inline]
       ip_rcv+0x18f/0x1a0 net/ipv4/ip_input.c:523
       __netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:5004
       __netif_receive_skb+0x37/0xf0 net/core/dev.c:5118
       netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5208
       napi_skb_finish net/core/dev.c:5671 [inline]
       napi_gro_receive+0x28f/0x330 net/core/dev.c:5704
       receive_buf+0x284/0x30b0 drivers/net/virtio_net.c:1061
       virtnet_receive drivers/net/virtio_net.c:1323 [inline]
       virtnet_poll+0x436/0x7d0 drivers/net/virtio_net.c:1428
       napi_poll net/core/dev.c:6352 [inline]
       net_rx_action+0x3ae/0xa50 net/core/dev.c:6418
      
      read to 0xffff88812ab369f8 of 8 bytes by task 7271 on cpu 0:
       tcp_recvmsg+0x470/0x1a30 net/ipv4/tcp.c:2047
       inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838
       sock_recvmsg_nosec net/socket.c:871 [inline]
       sock_recvmsg net/socket.c:889 [inline]
       sock_recvmsg+0x92/0xb0 net/socket.c:885
       sock_read_iter+0x15f/0x1e0 net/socket.c:967
       call_read_iter include/linux/fs.h:1864 [inline]
       new_sync_read+0x389/0x4f0 fs/read_write.c:414
       __vfs_read+0xb1/0xc0 fs/read_write.c:427
       vfs_read fs/read_write.c:461 [inline]
       vfs_read+0x143/0x2c0 fs/read_write.c:446
       ksys_read+0xd5/0x1b0 fs/read_write.c:587
       __do_sys_read fs/read_write.c:597 [inline]
       __se_sys_read fs/read_write.c:595 [inline]
       __x64_sys_read+0x4c/0x60 fs/read_write.c:595
       do_syscall_64+0xcf/0x2f0 arch/x86/entry/common.c:296
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 0 PID: 7271 Comm: syz-fuzzer Not tainted 5.3.0+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      8265792b
    • E
      tcp: annotate lockless access to tcp_memory_pressure · 1f142c17
      Eric Dumazet 提交于
      tcp_memory_pressure is read without holding any lock,
      and its value could be changed on other cpus.
      
      Use READ_ONCE() to annotate these lockless reads.
      
      The write side is already using atomic ops.
      
      Fixes: b8da51eb ("tcp: introduce tcp_under_memory_pressure()")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      1f142c17
    • E
      net: add {READ|WRITE}_ONCE() annotations on ->rskq_accept_head · 60b173ca
      Eric Dumazet 提交于
      reqsk_queue_empty() is called from inet_csk_listen_poll() while
      other cpus might write ->rskq_accept_head value.
      
      Use {READ|WRITE}_ONCE() to avoid compiler tricks
      and potential KCSAN splats.
      
      Fixes: fff1f300 ("tcp: add a spinlock to protect struct request_sock_queue")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      60b173ca
    • E
      net: avoid possible false sharing in sk_leave_memory_pressure() · 503978ac
      Eric Dumazet 提交于
      As mentioned in https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE#it-may-improve-performance
      a C compiler can legally transform :
      
      if (memory_pressure && *memory_pressure)
              *memory_pressure = 0;
      
      to :
      
      if (memory_pressure)
              *memory_pressure = 0;
      
      Fixes: 06044751 ("tcp: add TCPMemoryPressuresChrono counter")
      Fixes: 180d8cd9 ("foundations of per-cgroup memory pressure controlling.")
      Fixes: 3ab224be ("[NET] CORE: Introducing new memory accounting interface.")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      503978ac
    • E
      tun: remove possible false sharing in tun_flow_update() · 4ffdd22e
      Eric Dumazet 提交于
      As mentioned in https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE#it-may-improve-performance
      a C compiler can legally transform
      
      if (e->queue_index != queue_index)
      	e->queue_index = queue_index;
      
      to :
      
      	e->queue_index = queue_index;
      
      Note that the code using jiffies has no issue, since jiffies
      has volatile attribute.
      
      if (e->updated != jiffies)
          e->updated = jiffies;
      
      Fixes: 83b1bc12 ("tun: align write-heavy flow entry members to a cache line")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Zhang Yu <zhangyu31@baidu.com>
      Cc: Wang Li <wangli39@baidu.com>
      Cc: Li RongQing <lirongqing@baidu.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      4ffdd22e
    • E
      netfilter: conntrack: avoid possible false sharing · e37542ba
      Eric Dumazet 提交于
      As hinted by KCSAN, we need at least one READ_ONCE()
      to prevent a compiler optimization.
      
      More details on :
      https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE#it-may-improve-performance
      
      sysbot report :
      BUG: KCSAN: data-race in __nf_ct_refresh_acct / __nf_ct_refresh_acct
      
      read to 0xffff888123eb4f08 of 4 bytes by interrupt on cpu 0:
       __nf_ct_refresh_acct+0xd4/0x1b0 net/netfilter/nf_conntrack_core.c:1796
       nf_ct_refresh_acct include/net/netfilter/nf_conntrack.h:201 [inline]
       nf_conntrack_tcp_packet+0xd40/0x3390 net/netfilter/nf_conntrack_proto_tcp.c:1161
       nf_conntrack_handle_packet net/netfilter/nf_conntrack_core.c:1633 [inline]
       nf_conntrack_in+0x410/0xaa0 net/netfilter/nf_conntrack_core.c:1727
       ipv4_conntrack_in+0x27/0x40 net/netfilter/nf_conntrack_proto.c:178
       nf_hook_entry_hookfn include/linux/netfilter.h:135 [inline]
       nf_hook_slow+0x83/0x160 net/netfilter/core.c:512
       nf_hook include/linux/netfilter.h:260 [inline]
       NF_HOOK include/linux/netfilter.h:303 [inline]
       ip_rcv+0x12f/0x1a0 net/ipv4/ip_input.c:523
       __netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:5004
       __netif_receive_skb+0x37/0xf0 net/core/dev.c:5118
       netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5208
       napi_skb_finish net/core/dev.c:5671 [inline]
       napi_gro_receive+0x28f/0x330 net/core/dev.c:5704
       receive_buf+0x284/0x30b0 drivers/net/virtio_net.c:1061
       virtnet_receive drivers/net/virtio_net.c:1323 [inline]
       virtnet_poll+0x436/0x7d0 drivers/net/virtio_net.c:1428
       napi_poll net/core/dev.c:6352 [inline]
       net_rx_action+0x3ae/0xa50 net/core/dev.c:6418
       __do_softirq+0x115/0x33f kernel/softirq.c:292
      
      write to 0xffff888123eb4f08 of 4 bytes by task 7191 on cpu 1:
       __nf_ct_refresh_acct+0xfb/0x1b0 net/netfilter/nf_conntrack_core.c:1797
       nf_ct_refresh_acct include/net/netfilter/nf_conntrack.h:201 [inline]
       nf_conntrack_tcp_packet+0xd40/0x3390 net/netfilter/nf_conntrack_proto_tcp.c:1161
       nf_conntrack_handle_packet net/netfilter/nf_conntrack_core.c:1633 [inline]
       nf_conntrack_in+0x410/0xaa0 net/netfilter/nf_conntrack_core.c:1727
       ipv4_conntrack_local+0xbe/0x130 net/netfilter/nf_conntrack_proto.c:200
       nf_hook_entry_hookfn include/linux/netfilter.h:135 [inline]
       nf_hook_slow+0x83/0x160 net/netfilter/core.c:512
       nf_hook include/linux/netfilter.h:260 [inline]
       __ip_local_out+0x1f7/0x2b0 net/ipv4/ip_output.c:114
       ip_local_out+0x31/0x90 net/ipv4/ip_output.c:123
       __ip_queue_xmit+0x3a8/0xa40 net/ipv4/ip_output.c:532
       ip_queue_xmit+0x45/0x60 include/net/ip.h:236
       __tcp_transmit_skb+0xdeb/0x1cd0 net/ipv4/tcp_output.c:1158
       __tcp_send_ack+0x246/0x300 net/ipv4/tcp_output.c:3685
       tcp_send_ack+0x34/0x40 net/ipv4/tcp_output.c:3691
       tcp_cleanup_rbuf+0x130/0x360 net/ipv4/tcp.c:1575
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 1 PID: 7191 Comm: syz-fuzzer Not tainted 5.3.0+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      
      Fixes: cc169213 ("netfilter: conntrack: avoid same-timeout update")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Jozsef Kadlecsik <kadlec@netfilter.org>
      Cc: Florian Westphal <fw@strlen.de>
      Acked-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      e37542ba
    • N
      netns: fix NLM_F_ECHO mechanism for RTM_NEWNSID · 993e4c92
      Nicolas Dichtel 提交于
      The flag NLM_F_ECHO aims to reply to the user the message notified to all
      listeners.
      It was not the case with the command RTM_NEWNSID, let's fix this.
      
      Fixes: 0c7aecd4 ("netns: add rtnl cmd to add and get peer netns ids")
      Reported-by: NGuillaume Nault <gnault@redhat.com>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NGuillaume Nault <gnault@redhat.com>
      Tested-by: NGuillaume Nault <gnault@redhat.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      993e4c92
    • D
      net: usb: qmi_wwan: add Telit 0x1050 composition · e0ae2c57
      Daniele Palmas 提交于
      This patch adds support for Telit FN980 0x1050 composition
      
      0x1050: tty, adb, rmnet, tty, tty, tty, tty
      Signed-off-by: NDaniele Palmas <dnlplm@gmail.com>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      e0ae2c57
    • Y
      act_mirred: Fix mirred_init_module error handling · 11c9a7d3
      YueHaibing 提交于
      If tcf_register_action failed, mirred_device_notifier
      should be unregistered.
      
      Fixes: 3b87956e ("net sched: fix race in mirred device removal")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      11c9a7d3
    • V
      net: taprio: Fix returning EINVAL when configuring without flags · a954380a
      Vinicius Costa Gomes 提交于
      When configuring a taprio instance if "flags" is not specified (or
      it's zero), taprio currently replies with an "Invalid argument" error.
      
      So, set the return value to zero after we are done with all the
      checks.
      
      Fixes: 9c66d156 ("taprio: Add support for hardware offloading")
      Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Acked-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      a954380a
    • J
      Merge branch 's390-qeth-fixes' · 8cd6f4fe
      Jakub Kicinski 提交于
      Julian Wiedmann says:
      
      ====================
      s390/qeth: fixes 2019-10-08
      
      Alexandra fixes two issues in the initialization code for vnicc cmds.
      One is an uninitialized variable when a cmd fails, the other that we
      wouldn't recover correctly if the device's supported features changed.
      ====================
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      8cd6f4fe
    • A
      s390/qeth: Fix initialization of vnicc cmd masks during set online · be40a86c
      Alexandra Winter 提交于
      Without this patch, a command bit in the supported commands mask is only
      ever set to unsupported during set online. If a command is ever marked as
      unsupported (e.g. because of error during qeth_l2_vnicc_query_cmds),
      subsequent successful initialization (offline/online) would not bring it
      back.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      be40a86c
    • A
      s390/qeth: Fix error handling during VNICC initialization · b528965b
      Alexandra Winter 提交于
      Smatch discovered the use of uninitialized variable sup_cmds
      in error paths.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      b528965b
    • R
      phylink: fix kernel-doc warnings · 9db74e51
      Randy Dunlap 提交于
      Fix kernel-doc warnings in phylink.c:
      
      ../drivers/net/phy/phylink.c:595: warning: Function parameter or member 'config' not described in 'phylink_create'
      ../drivers/net/phy/phylink.c:595: warning: Excess function parameter 'ndev' description in 'phylink_create'
      
      Fixes: 8796c892 ("phylink: add documentation for kernel APIs")
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      9db74e51
    • X
      sctp: add chunks to sk_backlog when the newsk sk_socket is not set · 819be810
      Xin Long 提交于
      This patch is to fix a NULL-ptr deref in selinux_socket_connect_helper:
      
        [...] kasan: GPF could be caused by NULL-ptr deref or user memory access
        [...] RIP: 0010:selinux_socket_connect_helper+0x94/0x460
        [...] Call Trace:
        [...]  selinux_sctp_bind_connect+0x16a/0x1d0
        [...]  security_sctp_bind_connect+0x58/0x90
        [...]  sctp_process_asconf+0xa52/0xfd0 [sctp]
        [...]  sctp_sf_do_asconf+0x785/0x980 [sctp]
        [...]  sctp_do_sm+0x175/0x5a0 [sctp]
        [...]  sctp_assoc_bh_rcv+0x285/0x5b0 [sctp]
        [...]  sctp_backlog_rcv+0x482/0x910 [sctp]
        [...]  __release_sock+0x11e/0x310
        [...]  release_sock+0x4f/0x180
        [...]  sctp_accept+0x3f9/0x5a0 [sctp]
        [...]  inet_accept+0xe7/0x720
      
      It was caused by that the 'newsk' sk_socket was not set before going to
      security sctp hook when processing asconf chunk with SCTP_PARAM_ADD_IP
      or SCTP_PARAM_SET_PRIMARY:
      
        inet_accept()->
          sctp_accept():
            lock_sock():
                lock listening 'sk'
                                                do_softirq():
                                                  sctp_rcv():  <-- [1]
                                                      asconf chunk arrives and
                                                      enqueued in 'sk' backlog
            sctp_sock_migrate():
                set asoc's sk to 'newsk'
            release_sock():
                sctp_backlog_rcv():
                  lock 'newsk'
                  sctp_process_asconf()  <-- [2]
                  unlock 'newsk'
          sock_graft():
              set sk_socket  <-- [3]
      
      As it shows, at [1] the asconf chunk would be put into the listening 'sk'
      backlog, as accept() was holding its sock lock. Then at [2] asconf would
      get processed with 'newsk' as asoc's sk had been set to 'newsk'. However,
      'newsk' sk_socket is not set until [3], while selinux_sctp_bind_connect()
      would deref it, then kernel crashed.
      
      Here to fix it by adding the chunk to sk_backlog until newsk sk_socket is
      set when .accept() is done.
      
      Note that sk->sk_socket can be NULL when the sock is closed, so SOCK_DEAD
      flag is also needed to check in sctp_newsk_ready().
      
      Thanks to Ondrej for reviewing the code.
      
      Fixes: d452930f ("selinux: Add SCTP support")
      Reported-by: NYing Xu <yinxu@redhat.com>
      Suggested-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      819be810
    • E
      bonding: fix potential NULL deref in bond_update_slave_arr · a7137534
      Eric Dumazet 提交于
      syzbot got a NULL dereference in bond_update_slave_arr() [1],
      happening after a failure to allocate bond->slave_arr
      
      A workqueue (bond_slave_arr_handler) is supposed to retry
      the allocation later, but if the slave is removed before
      the workqueue had a chance to complete, bond->slave_arr
      can still be NULL.
      
      [1]
      
      Failed to build slave-array.
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN PTI
      Modules linked in:
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:bond_update_slave_arr.cold+0xc6/0x198 drivers/net/bonding/bond_main.c:4039
      RSP: 0018:ffff88018fe33678 EFLAGS: 00010246
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc9000290b000
      RDX: 0000000000000000 RSI: ffffffff82b63037 RDI: ffff88019745ea20
      RBP: ffff88018fe33760 R08: ffff880170754280 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: ffff88019745ea00 R14: 0000000000000000 R15: ffff88018fe338b0
      FS:  00007febd837d700(0000) GS:ffff8801dad00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004540a0 CR3: 00000001c242e005 CR4: 00000000001626f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       [<ffffffff82b5b45e>] __bond_release_one+0x43e/0x500 drivers/net/bonding/bond_main.c:1923
       [<ffffffff82b5b966>] bond_release drivers/net/bonding/bond_main.c:2039 [inline]
       [<ffffffff82b5b966>] bond_do_ioctl+0x416/0x870 drivers/net/bonding/bond_main.c:3562
       [<ffffffff83ae25f4>] dev_ifsioc+0x6f4/0x940 net/core/dev_ioctl.c:328
       [<ffffffff83ae2e58>] dev_ioctl+0x1b8/0xc70 net/core/dev_ioctl.c:495
       [<ffffffff83995ffd>] sock_do_ioctl+0x1bd/0x300 net/socket.c:1088
       [<ffffffff83996a80>] sock_ioctl+0x300/0x5d0 net/socket.c:1196
       [<ffffffff81b124db>] vfs_ioctl fs/ioctl.c:47 [inline]
       [<ffffffff81b124db>] file_ioctl fs/ioctl.c:501 [inline]
       [<ffffffff81b124db>] do_vfs_ioctl+0xacb/0x1300 fs/ioctl.c:688
       [<ffffffff81b12dc6>] SYSC_ioctl fs/ioctl.c:705 [inline]
       [<ffffffff81b12dc6>] SyS_ioctl+0xb6/0xe0 fs/ioctl.c:696
       [<ffffffff8101ccc8>] do_syscall_64+0x528/0x770 arch/x86/entry/common.c:305
       [<ffffffff84400091>] entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      Fixes: ee637714 ("bonding: Simplify the xmit function for modes that use xmit_hash")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Mahesh Bandewar <maheshb@google.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      a7137534
    • A
      net: stmmac: fix disabling flexible PPS output · 520cf600
      Antonio Borneo 提交于
      Accordingly to Synopsys documentation [1] and [2], when bit PPSEN0
      in register MAC_PPS_CONTROL is set it selects the functionality
      command in the same register, otherwise selects the functionality
      control.
      Command functionality is required to either enable (command 0x2)
      and disable (command 0x5) the flexible PPS output, but the bit
      PPSEN0 is currently set only for enabling.
      
      Set the bit PPSEN0 to properly disable flexible PPS output.
      
      Tested on STM32MP15x, based on dwmac 4.10a.
      
      [1] DWC Ethernet QoS Databook 4.10a October 2014
      [2] DWC Ethernet QoS Databook 5.00a September 2017
      Signed-off-by: NAntonio Borneo <antonio.borneo@st.com>
      Fixes: 9a8a02c9 ("net: stmmac: Add Flexible PPS support")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      520cf600
    • A
      net: stmmac: fix length of PTP clock's name string · 5da202c8
      Antonio Borneo 提交于
      The field "name" in struct ptp_clock_info has a fixed size of 16
      chars and is used as zero terminated string by clock_name_show()
      in drivers/ptp/ptp_sysfs.c
      The current initialization value requires 17 chars to fit also the
      null termination, and this causes overflow to the next bytes in
      the struct when the string is read as null terminated:
      	hexdump -C /sys/class/ptp/ptp0/clock_name
      	00000000  73 74 6d 6d 61 63 5f 70  74 70 5f 63 6c 6f 63 6b  |stmmac_ptp_clock|
      	00000010  a0 ac b9 03 0a                                    |.....|
      where the extra 4 bytes (excluding the newline) after the string
      represent the integer 0x03b9aca0 = 62500000 assigned to the field
      "max_adj" that follows "name" in the same struct.
      
      There is no strict requirement for the "name" content and in the
      comment in ptp_clock_kernel.h it's reported it should just be 'A
      short "friendly name" to identify the clock'.
      Replace it with "stmmac ptp".
      Signed-off-by: NAntonio Borneo <antonio.borneo@st.com>
      Fixes: 92ba6888 ("stmmac: add the support for PTP hw clock driver")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      5da202c8
  4. 09 10月, 2019 12 次提交
    • H
      ip6erspan: remove the incorrect mtu limit for ip6erspan · 4123f637
      Haishuang Yan 提交于
      ip6erspan driver calls ether_setup(), after commit 61e84623
      ("net: centralize net_device min/max MTU checking"), the range
      of mtu is [min_mtu, max_mtu], which is [68, 1500] by default.
      
      It causes the dev mtu of the erspan device to not be greater
      than 1500, this limit value is not correct for ip6erspan tap
      device.
      
      Fixes: 61e84623 ("net: centralize net_device min/max MTU checking")
      Signed-off-by: NHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Acked-by: NWilliam Tu <u9012063@gmail.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      4123f637
    • J
      Merge tag 'mac80211-for-davem-2019-10-08' of... · a17fd2cf
      Jakub Kicinski 提交于
      Merge tag 'mac80211-for-davem-2019-10-08' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      A number of fixes:
       * allow scanning when operating on radar channels in
         ETSI regdomains
       * accept deauth frames in IBSS - we have code to parse
         and handle them, but were dropping them early
       * fix an allocation failure path in hwsim
       * fix a failure path memory leak in nl80211 FTM code
       * fix RCU handling & locking in multi-BSSID parsing
       * reject malformed SSID in mac80211 (this shouldn't
         really be able to happen, but defense in depth)
       * avoid userspace buffer overrun in ancient wext code
         if SSID was too long
      ====================
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      a17fd2cf
    • R
      Doc: networking/device_drivers/pensando: fix ionic.rst warnings · b82316d2
      Randy Dunlap 提交于
      Fix documentation build warnings for Pensando ionic:
      
      Documentation/networking/device_drivers/pensando/ionic.rst:39: WARNING: Unexpected indentation.
      Documentation/networking/device_drivers/pensando/ionic.rst:43: WARNING: Unexpected indentation.
      
      Fixes: df69ba43 ("ionic: Add basic framework for IONIC Network device driver")
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Acked-by: NShannon Nelson <snelson@pensando.io>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      b82316d2
    • J
      NFC: pn533: fix use-after-free and memleaks · 6af3aa57
      Johan Hovold 提交于
      The driver would fail to deregister and its class device and free
      related resources on late probe errors.
      
      Reported-by: syzbot+cb035c75c03dbe34b796@syzkaller.appspotmail.com
      Fixes: 32ecc75d ("NFC: pn533: change order operations in dev registation")
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      6af3aa57
    • C
      net_sched: fix backward compatibility for TCA_ACT_KIND · 4b793fec
      Cong Wang 提交于
      For TCA_ACT_KIND, we have to keep the backward compatibility too,
      and rely on nla_strlcpy() to check and terminate the string with
      a NUL.
      
      Note for TC actions, nla_strcmp() is already used to compare kind
      strings, so we don't need to fix other places.
      
      Fixes: 199ce850 ("net_sched: add policy validation for action attributes")
      Reported-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      4b793fec
    • C
      net_sched: fix backward compatibility for TCA_KIND · 6f96c3c6
      Cong Wang 提交于
      Marcelo noticed a backward compatibility issue of TCA_KIND
      after we move from NLA_STRING to NLA_NUL_STRING, so it is probably
      too late to change it.
      
      Instead, to make everyone happy, we can just insert a NUL to
      terminate the string with nla_strlcpy() like we do for TC actions.
      
      Fixes: 62794fc4 ("net_sched: add max len check for TCA_KIND")
      Reported-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      6f96c3c6
    • A
      net/mlx5: DR, Allow insertion of duplicate rules · 00414126
      Alex Vesker 提交于
      Duplicate rules were not allowed to be configured with SW steering.
      This restriction caused failures with the replace rule logic done by
      upper layers.
      
      This fix allows for multiple rules with the same match values, in
      such case the first inserted rules will match.
      
      Fixes: 41d07074 ("net/mlx5: DR, Expose steering rule functionality")
      Signed-off-by: NAlex Vesker <valex@mellanox.com>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      00414126
    • J
      Merge branch 'llc-fix-sk_buff-refcounting' · 38dc3b5f
      Jakub Kicinski 提交于
      Eric Biggers says:
      
      ====================
      Patches 1-2 fix the memory leaks that syzbot has reported in net/llc:
      
      	memory leak in llc_ui_create (2)
      	memory leak in llc_ui_sendmsg
      	memory leak in llc_conn_ac_send_sabme_cmd_p_set_x
      
      Patches 3-4 fix related bugs that I noticed while reading this code.
      
      Note: I've tested that this fixes the syzbot bugs, but otherwise I don't
      know of any way to test this code.
      ====================
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      38dc3b5f
    • E
      llc: fix sk_buff refcounting in llc_conn_state_process() · 36453c85
      Eric Biggers 提交于
      If llc_conn_state_process() sees that llc_conn_service() put the skb on
      a list, it will drop one fewer references to it.  This is wrong because
      the current behavior is that llc_conn_service() never consumes a
      reference to the skb.
      
      The code also makes the number of skb references being dropped
      conditional on which of ind_prim and cfm_prim are nonzero, yet neither
      of these affects how many references are *acquired*.  So there is extra
      code that tries to fix this up by sometimes taking another reference.
      
      Remove the unnecessary/broken refcounting logic and instead just add an
      skb_get() before the only two places where an extra reference is
      actually consumed.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      36453c85
    • E
      llc: fix another potential sk_buff leak in llc_ui_sendmsg() · fc8d5db1
      Eric Biggers 提交于
      All callers of llc_conn_state_process() except llc_build_and_send_pkt()
      (via llc_ui_sendmsg() -> llc_ui_send_data()) assume that it always
      consumes a reference to the skb.  Fix this caller to do the same.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      fc8d5db1
    • E
      llc: fix sk_buff leak in llc_conn_service() · b74555de
      Eric Biggers 提交于
      syzbot reported:
      
          BUG: memory leak
          unreferenced object 0xffff88811eb3de00 (size 224):
             comm "syz-executor559", pid 7315, jiffies 4294943019 (age 10.300s)
             hex dump (first 32 bytes):
               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
               00 a0 38 24 81 88 ff ff 00 c0 f2 15 81 88 ff ff  ..8$............
             backtrace:
               [<000000008d1c66a1>] kmemleak_alloc_recursive  include/linux/kmemleak.h:55 [inline]
               [<000000008d1c66a1>] slab_post_alloc_hook mm/slab.h:439 [inline]
               [<000000008d1c66a1>] slab_alloc_node mm/slab.c:3269 [inline]
               [<000000008d1c66a1>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
               [<00000000447d9496>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198
               [<000000000cdbf82f>] alloc_skb include/linux/skbuff.h:1058 [inline]
               [<000000000cdbf82f>] llc_alloc_frame+0x66/0x110 net/llc/llc_sap.c:54
               [<000000002418b52e>] llc_conn_ac_send_sabme_cmd_p_set_x+0x2f/0x140  net/llc/llc_c_ac.c:777
               [<000000001372ae17>] llc_exec_conn_trans_actions net/llc/llc_conn.c:475  [inline]
               [<000000001372ae17>] llc_conn_service net/llc/llc_conn.c:400 [inline]
               [<000000001372ae17>] llc_conn_state_process+0x1ac/0x640  net/llc/llc_conn.c:75
               [<00000000f27e53c1>] llc_establish_connection+0x110/0x170  net/llc/llc_if.c:109
               [<00000000291b2ca0>] llc_ui_connect+0x10e/0x370 net/llc/af_llc.c:477
               [<000000000f9c740b>] __sys_connect+0x11d/0x170 net/socket.c:1840
               [...]
      
      The bug is that most callers of llc_conn_send_pdu() assume it consumes a
      reference to the skb, when actually due to commit b85ab56c ("llc:
      properly handle dev_queue_xmit() return value") it doesn't.
      
      Revert most of that commit, and instead make the few places that need
      llc_conn_send_pdu() to *not* consume a reference call skb_get() before.
      
      Fixes: b85ab56c ("llc: properly handle dev_queue_xmit() return value")
      Reported-by: syzbot+6b825a6494a04cc0e3f7@syzkaller.appspotmail.com
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      b74555de
    • E
      llc: fix sk_buff leak in llc_sap_state_process() · c6ee11c3
      Eric Biggers 提交于
      syzbot reported:
      
          BUG: memory leak
          unreferenced object 0xffff888116270800 (size 224):
             comm "syz-executor641", pid 7047, jiffies 4294947360 (age 13.860s)
             hex dump (first 32 bytes):
               00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
               00 20 e1 2a 81 88 ff ff 00 40 3d 2a 81 88 ff ff  . .*.....@=*....
             backtrace:
               [<000000004d41b4cc>] kmemleak_alloc_recursive  include/linux/kmemleak.h:55 [inline]
               [<000000004d41b4cc>] slab_post_alloc_hook mm/slab.h:439 [inline]
               [<000000004d41b4cc>] slab_alloc_node mm/slab.c:3269 [inline]
               [<000000004d41b4cc>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
               [<00000000506a5965>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198
               [<000000001ba5a161>] alloc_skb include/linux/skbuff.h:1058 [inline]
               [<000000001ba5a161>] alloc_skb_with_frags+0x5f/0x250  net/core/skbuff.c:5327
               [<0000000047d9c78b>] sock_alloc_send_pskb+0x269/0x2a0  net/core/sock.c:2225
               [<000000003828fe54>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242
               [<00000000e34d94f9>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
               [<00000000de2de3fb>] sock_sendmsg_nosec net/socket.c:652 [inline]
               [<00000000de2de3fb>] sock_sendmsg+0x54/0x70 net/socket.c:671
               [<000000008fe16e7a>] __sys_sendto+0x148/0x1f0 net/socket.c:1964
      	 [...]
      
      The bug is that llc_sap_state_process() always takes an extra reference
      to the skb, but sometimes neither llc_sap_next_state() nor
      llc_sap_state_process() itself drops this reference.
      
      Fix it by changing llc_sap_next_state() to never consume a reference to
      the skb, rather than sometimes do so and sometimes not.  Then remove the
      extra skb_get() and kfree_skb() from llc_sap_state_process().
      
      Reported-by: syzbot+6bf095f9becf5efef645@syzkaller.appspotmail.com
      Reported-by: syzbot+31c16aa4202dace3812e@syzkaller.appspotmail.com
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      c6ee11c3
  5. 08 10月, 2019 1 次提交