1. 09 8月, 2019 2 次提交
  2. 04 8月, 2019 3 次提交
  3. 31 7月, 2019 1 次提交
    • S
      hvsock: fix epollout hang from race condition · 49fb03de
      Sunil Muthuswamy 提交于
      [ Upstream commit cb359b60416701c8bed82fec79de25a144beb893 ]
      
      Currently, hvsock can enter into a state where epoll_wait on EPOLLOUT will
      not return even when the hvsock socket is writable, under some race
      condition. This can happen under the following sequence:
      - fd = socket(hvsocket)
      - fd_out = dup(fd)
      - fd_in = dup(fd)
      - start a writer thread that writes data to fd_out with a combination of
        epoll_wait(fd_out, EPOLLOUT) and
      - start a reader thread that reads data from fd_in with a combination of
        epoll_wait(fd_in, EPOLLIN)
      - On the host, there are two threads that are reading/writing data to the
        hvsocket
      
      stack:
      hvs_stream_has_space
      hvs_notify_poll_out
      vsock_poll
      sock_poll
      ep_poll
      
      Race condition:
      check for epollout from ep_poll():
      	assume no writable space in the socket
      	hvs_stream_has_space() returns 0
      check for epollin from ep_poll():
      	assume socket has some free space < HVS_PKT_LEN(HVS_SEND_BUF_SIZE)
      	hvs_stream_has_space() will clear the channel pending send size
      	host will not notify the guest because the pending send size has
      		been cleared and so the hvsocket will never mark the
      		socket writable
      
      Now, the EPOLLOUT will never return even if the socket write buffer is
      empty.
      
      The fix is to set the pending size to the default size and never change it.
      This way the host will always notify the guest whenever the writable space
      is bigger than the pending size. The host is already optimized to *only*
      notify the guest when the pending size threshold boundary is crossed and
      not everytime.
      
      This change also reduces the cpu usage somewhat since hv_stream_has_space()
      is in the hotpath of send:
      vsock_stream_sendmsg()->hv_stream_has_space()
      Earlier hv_stream_has_space was setting/clearing the pending size on every
      call.
      Signed-off-by: NSunil Muthuswamy <sunilmut@microsoft.com>
      Reviewed-by: NDexuan Cui <decui@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      49fb03de
  4. 28 7月, 2019 23 次提交
    • V
      net: sched: verify that q!=NULL before setting q->flags · 60e9babf
      Vlad Buslov 提交于
      commit 503d81d428bd598430f7f9d02021634e1a8139a0 upstream.
      
      In function int tc_new_tfilter() q pointer can be NULL when adding filter
      on a shared block. With recent change that resets TCQ_F_CAN_BYPASS after
      filter creation, following NULL pointer dereference happens in case parent
      block is shared:
      
      [  212.925060] BUG: kernel NULL pointer dereference, address: 0000000000000010
      [  212.925445] #PF: supervisor write access in kernel mode
      [  212.925709] #PF: error_code(0x0002) - not-present page
      [  212.925965] PGD 8000000827923067 P4D 8000000827923067 PUD 827924067 PMD 0
      [  212.926302] Oops: 0002 [#1] SMP KASAN PTI
      [  212.926539] CPU: 18 PID: 2617 Comm: tc Tainted: G    B             5.2.0+ #512
      [  212.926938] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017
      [  212.927364] RIP: 0010:tc_new_tfilter+0x698/0xd40
      [  212.927633] Code: 74 0d 48 85 c0 74 08 48 89 ef e8 03 aa 62 00 48 8b 84 24 a0 00 00 00 48 8d 78 10 48 89 44 24 18 e8 4d 0c 6b ff 48 8b 44 24 18 <83> 60 10 f
      b 48 85 ed 0f 85 3d fe ff ff e9 4f fe ff ff e8 81 26 f8
      [  212.928607] RSP: 0018:ffff88884fd5f5d8 EFLAGS: 00010296
      [  212.928905] RAX: 0000000000000000 RBX: 0000000000000000 RCX: dffffc0000000000
      [  212.929201] RDX: 0000000000000007 RSI: 0000000000000004 RDI: 0000000000000297
      [  212.929402] RBP: ffff88886bedd600 R08: ffffffffb91d4b51 R09: fffffbfff7616e4d
      [  212.929609] R10: fffffbfff7616e4c R11: ffffffffbb0b7263 R12: ffff88886bc61040
      [  212.929803] R13: ffff88884fd5f950 R14: ffffc900039c5000 R15: ffff88835e927680
      [  212.929999] FS:  00007fe7c50b6480(0000) GS:ffff88886f980000(0000) knlGS:0000000000000000
      [  212.930235] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  212.930394] CR2: 0000000000000010 CR3: 000000085bd04002 CR4: 00000000001606e0
      [  212.930588] Call Trace:
      [  212.930682]  ? tc_del_tfilter+0xa40/0xa40
      [  212.930811]  ? __lock_acquire+0x5b5/0x2460
      [  212.930948]  ? find_held_lock+0x85/0xa0
      [  212.931081]  ? tc_del_tfilter+0xa40/0xa40
      [  212.931201]  rtnetlink_rcv_msg+0x4ab/0x5f0
      [  212.931332]  ? rtnl_dellink+0x490/0x490
      [  212.931454]  ? lockdep_hardirqs_on+0x260/0x260
      [  212.931589]  ? netlink_deliver_tap+0xab/0x5a0
      [  212.931717]  ? match_held_lock+0x1b/0x240
      [  212.931844]  netlink_rcv_skb+0xd0/0x200
      [  212.931958]  ? rtnl_dellink+0x490/0x490
      [  212.932079]  ? netlink_ack+0x440/0x440
      [  212.932205]  ? netlink_deliver_tap+0x161/0x5a0
      [  212.932335]  ? lock_downgrade+0x360/0x360
      [  212.932457]  ? lock_acquire+0xe5/0x210
      [  212.932579]  netlink_unicast+0x296/0x350
      [  212.932705]  ? netlink_attachskb+0x390/0x390
      [  212.932834]  ? _copy_from_iter_full+0xe0/0x3a0
      [  212.932976]  netlink_sendmsg+0x394/0x600
      [  212.937998]  ? netlink_unicast+0x350/0x350
      [  212.943033]  ? move_addr_to_kernel.part.0+0x90/0x90
      [  212.948115]  ? netlink_unicast+0x350/0x350
      [  212.953185]  sock_sendmsg+0x96/0xa0
      [  212.958099]  ___sys_sendmsg+0x482/0x520
      [  212.962881]  ? match_held_lock+0x1b/0x240
      [  212.967618]  ? copy_msghdr_from_user+0x250/0x250
      [  212.972337]  ? lock_downgrade+0x360/0x360
      [  212.976973]  ? rwlock_bug.part.0+0x60/0x60
      [  212.981548]  ? __mod_node_page_state+0x1f/0xa0
      [  212.986060]  ? match_held_lock+0x1b/0x240
      [  212.990567]  ? find_held_lock+0x85/0xa0
      [  212.994989]  ? do_user_addr_fault+0x349/0x5b0
      [  212.999387]  ? lock_downgrade+0x360/0x360
      [  213.003713]  ? find_held_lock+0x85/0xa0
      [  213.007972]  ? __fget_light+0xa1/0xf0
      [  213.012143]  ? sockfd_lookup_light+0x91/0xb0
      [  213.016165]  __sys_sendmsg+0xba/0x130
      [  213.020040]  ? __sys_sendmsg_sock+0xb0/0xb0
      [  213.023870]  ? handle_mm_fault+0x337/0x470
      [  213.027592]  ? page_fault+0x8/0x30
      [  213.031316]  ? lockdep_hardirqs_off+0xbe/0x100
      [  213.034999]  ? mark_held_locks+0x24/0x90
      [  213.038671]  ? do_syscall_64+0x1e/0xe0
      [  213.042297]  do_syscall_64+0x74/0xe0
      [  213.045828]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  213.049354] RIP: 0033:0x7fe7c527c7b8
      [  213.052792] Code: 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 8f 0c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f
      0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 54
      [  213.060269] RSP: 002b:00007ffc3f7908a8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      [  213.064144] RAX: ffffffffffffffda RBX: 000000005d34716f RCX: 00007fe7c527c7b8
      [  213.068094] RDX: 0000000000000000 RSI: 00007ffc3f790910 RDI: 0000000000000003
      [  213.072109] RBP: 0000000000000000 R08: 0000000000000001 R09: 00007fe7c5340cc0
      [  213.076113] R10: 0000000000404ec2 R11: 0000000000000246 R12: 0000000000000080
      [  213.080146] R13: 0000000000480640 R14: 0000000000000080 R15: 0000000000000000
      [  213.084147] Modules linked in: act_gact cls_flower sch_ingress nfsv3 nfs_acl nfs lockd grace fscache bridge stp llc sunrpc intel_rapl_msr intel_rapl_common
      [<1;69;32Msb_edac rdma_ucm rdma_cm x86_pkg_temp_thermal iw_cm intel_powerclamp ib_cm coretemp kvm_intel kvm irqbypass mlx5_ib ib_uverbs ib_core crct10dif_pclmul crc32_pc
      lmul crc32c_intel ghash_clmulni_intel mlx5_core intel_cstate intel_uncore iTCO_wdt igb iTCO_vendor_support mlxfw mei_me ptp ses intel_rapl_perf mei pcspkr ipmi
      _ssif i2c_i801 joydev enclosure pps_core lpc_ich ioatdma wmi dca ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter acpi_pad ast i2c_algo_bit drm_vram_helpe
      r ttm drm_kms_helper drm mpt3sas raid_class scsi_transport_sas
      [  213.112326] CR2: 0000000000000010
      [  213.117429] ---[ end trace adb58eb0a4ee6283 ]---
      
      Verify that q pointer is not NULL before setting the 'flags' field.
      
      Fixes: 3f05e6886a59 ("net_sched: unset TCQ_F_CAN_BYPASS when adding filters")
      Signed-off-by: NVlad Buslov <vladbu@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Cc: Sasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      60e9babf
    • N
      net: bridge: stp: don't cache eth dest pointer before skb pull · b72fb8de
      Nikolay Aleksandrov 提交于
      [ Upstream commit 2446a68ae6a8cee6d480e2f5b52f5007c7c41312 ]
      
      Don't cache eth dest pointer before calling pskb_may_pull.
      
      Fixes: cf0f02d0 ("[BRIDGE]: use llc for receiving STP packets")
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b72fb8de
    • N
      net: bridge: don't cache ether dest pointer on input · 78701843
      Nikolay Aleksandrov 提交于
      [ Upstream commit 3d26eb8ad1e9b906433903ce05f775cf038e747f ]
      
      We would cache ether dst pointer on input in br_handle_frame_finish but
      after the neigh suppress code that could lead to a stale pointer since
      both ipv4 and ipv6 suppress code do pskb_may_pull. This means we have to
      always reload it after the suppress code so there's no point in having
      it cached just retrieve it directly.
      
      Fixes: 057658cb ("bridge: suppress arp pkts on BR_NEIGH_SUPPRESS ports")
      Fixes: ed842fae ("bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports")
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      78701843
    • N
      net: bridge: mcast: fix stale ipv6 hdr pointer when handling v6 query · 41a8df71
      Nikolay Aleksandrov 提交于
      [ Upstream commit 3b26a5d03d35d8f732d75951218983c0f7f68dff ]
      
      We get a pointer to the ipv6 hdr in br_ip6_multicast_query but we may
      call pskb_may_pull afterwards and end up using a stale pointer.
      So use the header directly, it's just 1 place where it's needed.
      
      Fixes: 08b202b6 ("bridge br_multicast: IPv6 MLD support.")
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Tested-by: NMartin Weinelt <martin@linuxlounge.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      41a8df71
    • N
      net: bridge: mcast: fix stale nsrcs pointer in igmp3/mld2 report handling · caf4488f
      Nikolay Aleksandrov 提交于
      [ Upstream commit e57f61858b7cf478ed6fa23ed4b3876b1c9625c4 ]
      
      We take a pointer to grec prior to calling pskb_may_pull and use it
      afterwards to get nsrcs so record nsrcs before the pull when handling
      igmp3 and we get a pointer to nsrcs and call pskb_may_pull when handling
      mld2 which again could lead to reading 2 bytes out-of-bounds.
      
       ==================================================================
       BUG: KASAN: use-after-free in br_multicast_rcv+0x480c/0x4ad0 [bridge]
       Read of size 2 at addr ffff8880421302b4 by task ksoftirqd/1/16
      
       CPU: 1 PID: 16 Comm: ksoftirqd/1 Tainted: G           OE     5.2.0-rc6+ #1
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
       Call Trace:
        dump_stack+0x71/0xab
        print_address_description+0x6a/0x280
        ? br_multicast_rcv+0x480c/0x4ad0 [bridge]
        __kasan_report+0x152/0x1aa
        ? br_multicast_rcv+0x480c/0x4ad0 [bridge]
        ? br_multicast_rcv+0x480c/0x4ad0 [bridge]
        kasan_report+0xe/0x20
        br_multicast_rcv+0x480c/0x4ad0 [bridge]
        ? br_multicast_disable_port+0x150/0x150 [bridge]
        ? ktime_get_with_offset+0xb4/0x150
        ? __kasan_kmalloc.constprop.6+0xa6/0xf0
        ? __netif_receive_skb+0x1b0/0x1b0
        ? br_fdb_update+0x10e/0x6e0 [bridge]
        ? br_handle_frame_finish+0x3c6/0x11d0 [bridge]
        br_handle_frame_finish+0x3c6/0x11d0 [bridge]
        ? br_pass_frame_up+0x3a0/0x3a0 [bridge]
        ? virtnet_probe+0x1c80/0x1c80 [virtio_net]
        br_handle_frame+0x731/0xd90 [bridge]
        ? select_idle_sibling+0x25/0x7d0
        ? br_handle_frame_finish+0x11d0/0x11d0 [bridge]
        __netif_receive_skb_core+0xced/0x2d70
        ? virtqueue_get_buf_ctx+0x230/0x1130 [virtio_ring]
        ? do_xdp_generic+0x20/0x20
        ? virtqueue_napi_complete+0x39/0x70 [virtio_net]
        ? virtnet_poll+0x94d/0xc78 [virtio_net]
        ? receive_buf+0x5120/0x5120 [virtio_net]
        ? __netif_receive_skb_one_core+0x97/0x1d0
        __netif_receive_skb_one_core+0x97/0x1d0
        ? __netif_receive_skb_core+0x2d70/0x2d70
        ? _raw_write_trylock+0x100/0x100
        ? __queue_work+0x41e/0xbe0
        process_backlog+0x19c/0x650
        ? _raw_read_lock_irq+0x40/0x40
        net_rx_action+0x71e/0xbc0
        ? __switch_to_asm+0x40/0x70
        ? napi_complete_done+0x360/0x360
        ? __switch_to_asm+0x34/0x70
        ? __switch_to_asm+0x40/0x70
        ? __schedule+0x85e/0x14d0
        __do_softirq+0x1db/0x5f9
        ? takeover_tasklets+0x5f0/0x5f0
        run_ksoftirqd+0x26/0x40
        smpboot_thread_fn+0x443/0x680
        ? sort_range+0x20/0x20
        ? schedule+0x94/0x210
        ? __kthread_parkme+0x78/0xf0
        ? sort_range+0x20/0x20
        kthread+0x2ae/0x3a0
        ? kthread_create_worker_on_cpu+0xc0/0xc0
        ret_from_fork+0x35/0x40
      
       The buggy address belongs to the page:
       page:ffffea0001084c00 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0
       flags: 0xffffc000000000()
       raw: 00ffffc000000000 ffffea0000cfca08 ffffea0001098608 0000000000000000
       raw: 0000000000000000 0000000000000003 00000000ffffff7f 0000000000000000
       page dumped because: kasan: bad access detected
      
       Memory state around the buggy address:
       ffff888042130180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff888042130200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       > ffff888042130280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                                           ^
       ffff888042130300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff888042130380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ==================================================================
       Disabling lock debugging due to kernel taint
      
      Fixes: bc8c20ac ("bridge: multicast: treat igmpv3 report with INCLUDE and no sources as a leave")
      Reported-by: NMartin Weinelt <martin@linuxlounge.net>
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Tested-by: NMartin Weinelt <martin@linuxlounge.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      caf4488f
    • X
      sctp: not bind the socket in sctp_connect · bc9a2f36
      Xin Long 提交于
      [ Upstream commit 9b6c08878e23adb7cc84bdca94d8a944b03f099e ]
      
      Now when sctp_connect() is called with a wrong sa_family, it binds
      to a port but doesn't set bp->port, then sctp_get_af_specific will
      return NULL and sctp_connect() returns -EINVAL.
      
      Then if sctp_bind() is called to bind to another port, the last
      port it has bound will leak due to bp->port is NULL by then.
      
      sctp_connect() doesn't need to bind ports, as later __sctp_connect
      will do it if bp->port is NULL. So remove it from sctp_connect().
      While at it, remove the unnecessary sockaddr.sa_family len check
      as it's already done in sctp_inet_connect.
      
      Fixes: 644fbdea ("sctp: fix the issue that flags are ignored when using kernel_connect")
      Reported-by: syzbot+079bf326b38072f849d9@syzkaller.appspotmail.com
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc9a2f36
    • J
      net/tls: make sure offload also gets the keys wiped · fde351ae
      Jakub Kicinski 提交于
      [ Upstream commit acd3e96d53a24d219f720ed4012b62723ae05da1 ]
      
      Commit 86029d10 ("tls: zero the crypto information from tls_context
      before freeing") added memzero_explicit() calls to clear the key material
      before freeing struct tls_context, but it missed tls_device.c has its
      own way of freeing this structure. Replace the missing free.
      
      Fixes: 86029d10 ("tls: zero the crypto information from tls_context before freeing")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fde351ae
    • C
      net_sched: unset TCQ_F_CAN_BYPASS when adding filters · d9571a9f
      Cong Wang 提交于
      [ Upstream commit 3f05e6886a595c9a29a309c52f45326be917823c ]
      
      For qdisc's that support TC filters and set TCQ_F_CAN_BYPASS,
      notably fq_codel, it makes no sense to let packets bypass the TC
      filters we setup in any scenario, otherwise our packets steering
      policy could not be enforced.
      
      This can be reproduced easily with the following script:
      
       ip li add dev dummy0 type dummy
       ifconfig dummy0 up
       tc qd add dev dummy0 root fq_codel
       tc filter add dev dummy0 parent 8001: protocol arp basic action mirred egress redirect dev lo
       tc filter add dev dummy0 parent 8001: protocol ip basic action mirred egress redirect dev lo
       ping -I dummy0 192.168.112.1
      
      Without this patch, packets are sent directly to dummy0 without
      hitting any of the filters. With this patch, packets are redirected
      to loopback as expected.
      
      This fix is not perfect, it only unsets the flag but does not set it back
      because we have to save the information somewhere in the qdisc if we
      really want that. Note, both fq_codel and sfq clear this flag in their
      ->bind_tcf() but this is clearly not sufficient when we don't use any
      class ID.
      
      Fixes: 23624935 ("net_sched: TCQ_F_CAN_BYPASS generalization")
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9571a9f
    • C
      netrom: hold sock when setting skb->destructor · 69cd5845
      Cong Wang 提交于
      [ Upstream commit 4638faac032756f7eab5524be7be56bee77e426b ]
      
      sock_efree() releases the sock refcnt, if we don't hold this refcnt
      when setting skb->destructor to it, the refcnt would not be balanced.
      This leads to several bug reports from syzbot.
      
      I have checked other users of sock_efree(), all of them hold the
      sock refcnt.
      
      Fixes: c8c8218ec5af ("netrom: fix a memory leak in nr_rx_frame()")
      Reported-and-tested-by: <syzbot+622bdabb128acc33427d@syzkaller.appspotmail.com>
      Reported-and-tested-by: <syzbot+6eaef7158b19e3fec3a0@syzkaller.appspotmail.com>
      Reported-and-tested-by: <syzbot+9399c158fcc09b21d0d2@syzkaller.appspotmail.com>
      Reported-and-tested-by: <syzbot+a34e5f3d0300163f0c87@syzkaller.appspotmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      69cd5845
    • C
      netrom: fix a memory leak in nr_rx_frame() · dc59a2ab
      Cong Wang 提交于
      [ Upstream commit c8c8218ec5af5d2598381883acbefbf604e56b5e ]
      
      When the skb is associated with a new sock, just assigning
      it to skb->sk is not sufficient, we have to set its destructor
      to free the sock properly too.
      
      Reported-by: syzbot+d6636a36d3c34bd88938@syzkaller.appspotmail.com
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc59a2ab
    • C
      tcp: Reset bytes_acked and bytes_received when disconnecting · 1b200acd
      Christoph Paasch 提交于
      [ Upstream commit e858faf556d4e14c750ba1e8852783c6f9520a0e ]
      
      If an app is playing tricks to reuse a socket via tcp_disconnect(),
      bytes_acked/received needs to be reset to 0. Otherwise tcp_info will
      report the sum of the current and the old connection..
      
      Cc: Eric Dumazet <edumazet@google.com>
      Fixes: 0df48c26 ("tcp: add tcpi_bytes_acked to tcp_info")
      Fixes: bdd1f9ed ("tcp: add tcpi_bytes_received to tcp_info")
      Signed-off-by: NChristoph Paasch <cpaasch@apple.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b200acd
    • E
      tcp: fix tcp_set_congestion_control() use from bpf hook · c60f57df
      Eric Dumazet 提交于
      [ Upstream commit 8d650cdedaabb33e85e9b7c517c0c71fcecc1de9 ]
      
      Neal reported incorrect use of ns_capable() from bpf hook.
      
      bpf_setsockopt(...TCP_CONGESTION...)
        -> tcp_set_congestion_control()
         -> ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN)
          -> ns_capable_common()
           -> current_cred()
            -> rcu_dereference_protected(current->cred, 1)
      
      Accessing 'current' in bpf context makes no sense, since packets
      are processed from softirq context.
      
      As Neal stated : The capability check in tcp_set_congestion_control()
      was written assuming a system call context, and then was reused from
      a BPF call site.
      
      The fix is to add a new parameter to tcp_set_congestion_control(),
      so that the ns_capable() call is only performed under the right
      context.
      
      Fixes: 91b5b21c ("bpf: Add support for changing congestion control")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Lawrence Brakmo <brakmo@fb.com>
      Reported-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NLawrence Brakmo <brakmo@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c60f57df
    • E
      tcp: be more careful in tcp_fragment() · 6323c238
      Eric Dumazet 提交于
      [ Upstream commit b617158dc096709d8600c53b6052144d12b89fab ]
      
      Some applications set tiny SO_SNDBUF values and expect
      TCP to just work. Recent patches to address CVE-2019-11478
      broke them in case of losses, since retransmits might
      be prevented.
      
      We should allow these flows to make progress.
      
      This patch allows the first and last skb in retransmit queue
      to be split even if memory limits are hit.
      
      It also adds the some room due to the fact that tcp_sendmsg()
      and tcp_sendpage() might overshoot sk_wmem_queued by about one full
      TSO skb (64KB size). Note this allowance was already present
      in stable backports for kernels < 4.15
      
      Note for < 4.15 backports :
       tcp_rtx_queue_tail() will probably look like :
      
      static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
      {
      	struct sk_buff *skb = tcp_send_head(sk);
      
      	return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
      }
      
      Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NAndrew Prout <aprout@ll.mit.edu>
      Tested-by: NAndrew Prout <aprout@ll.mit.edu>
      Tested-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Tested-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NYuchung Cheng <ycheng@google.com>
      Acked-by: NChristoph Paasch <cpaasch@apple.com>
      Cc: Jonathan Looney <jtl@netflix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6323c238
    • M
      sctp: fix error handling on stream scheduler initialization · d9ee5afd
      Marcelo Ricardo Leitner 提交于
      [ Upstream commit 4d1415811e492d9a8238f8a92dd0d51612c788e9 ]
      
      It allocates the extended area for outbound streams only on sendmsg
      calls, if they are not yet allocated.  When using the priority
      stream scheduler, this initialization may imply into a subsequent
      allocation, which may fail.  In this case, it was aborting the stream
      scheduler initialization but leaving the ->ext pointer (allocated) in
      there, thus in a partially initialized state.  On a subsequent call to
      sendmsg, it would notice the ->ext pointer in there, and trip on
      uninitialized stuff when trying to schedule the data chunk.
      
      The fix is undo the ->ext initialization if the stream scheduler
      initialization fails and avoid the partially initialized state.
      
      Although syzkaller bisected this to commit 4ff40b86262b ("sctp: set
      chunk transport correctly when it's a new asoc"), this bug was actually
      introduced on the commit I marked below.
      
      Reported-by: syzbot+c1a380d42b190ad1e559@syzkaller.appspotmail.com
      Fixes: 5bbbbe32 ("sctp: introduce stream scheduler foundations")
      Tested-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: NNeil Horman <nhorman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9ee5afd
    • D
      rxrpc: Fix send on a connected, but unbound socket · bfa79135
      David Howells 提交于
      [ Upstream commit e835ada07091f40dcfb1bc735082bd0a7c005e59 ]
      
      If sendmsg() or sendmmsg() is called on a connected socket that hasn't had
      bind() called on it, then an oops will occur when the kernel tries to
      connect the call because no local endpoint has been allocated.
      
      Fix this by implicitly binding the socket if it is in the
      RXRPC_CLIENT_UNBOUND state, just like it does for the RXRPC_UNBOUND state.
      
      Further, the state should be transitioned to RXRPC_CLIENT_BOUND after this
      to prevent further attempts to bind it.
      
      This can be tested with:
      
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <string.h>
      	#include <sys/socket.h>
      	#include <arpa/inet.h>
      	#include <linux/rxrpc.h>
      	static const unsigned char inet6_addr[16] = {
      		0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -1, -1, 0xac, 0x14, 0x14, 0xaa
      	};
      	int main(void)
      	{
      		struct sockaddr_rxrpc srx;
      		struct cmsghdr *cm;
      		struct msghdr msg;
      		unsigned char control[16];
      		int fd;
      		memset(&srx, 0, sizeof(srx));
      		srx.srx_family = 0x21;
      		srx.srx_service = 0;
      		srx.transport_type = AF_INET;
      		srx.transport_len = 0x1c;
      		srx.transport.sin6.sin6_family = AF_INET6;
      		srx.transport.sin6.sin6_port = htons(0x4e22);
      		srx.transport.sin6.sin6_flowinfo = htons(0x4e22);
      		srx.transport.sin6.sin6_scope_id = htons(0xaa3b);
      		memcpy(&srx.transport.sin6.sin6_addr, inet6_addr, 16);
      		cm = (struct cmsghdr *)control;
      		cm->cmsg_len	= CMSG_LEN(sizeof(unsigned long));
      		cm->cmsg_level	= SOL_RXRPC;
      		cm->cmsg_type	= RXRPC_USER_CALL_ID;
      		*(unsigned long *)CMSG_DATA(cm) = 0;
      		msg.msg_name = NULL;
      		msg.msg_namelen = 0;
      		msg.msg_iov = NULL;
      		msg.msg_iovlen = 0;
      		msg.msg_control = control;
      		msg.msg_controllen = cm->cmsg_len;
      		msg.msg_flags = 0;
      		fd = socket(AF_RXRPC, SOCK_DGRAM, AF_INET);
      		connect(fd, (struct sockaddr *)&srx, sizeof(srx));
      		sendmsg(fd, &msg, 0);
      		return 0;
      	}
      
      Leading to the following oops:
      
      	BUG: kernel NULL pointer dereference, address: 0000000000000018
      	#PF: supervisor read access in kernel mode
      	#PF: error_code(0x0000) - not-present page
      	...
      	RIP: 0010:rxrpc_connect_call+0x42/0xa01
      	...
      	Call Trace:
      	 ? mark_held_locks+0x47/0x59
      	 ? __local_bh_enable_ip+0xb6/0xba
      	 rxrpc_new_client_call+0x3b1/0x762
      	 ? rxrpc_do_sendmsg+0x3c0/0x92e
      	 rxrpc_do_sendmsg+0x3c0/0x92e
      	 rxrpc_sendmsg+0x16b/0x1b5
      	 sock_sendmsg+0x2d/0x39
      	 ___sys_sendmsg+0x1a4/0x22a
      	 ? release_sock+0x19/0x9e
      	 ? reacquire_held_locks+0x136/0x160
      	 ? release_sock+0x19/0x9e
      	 ? find_held_lock+0x2b/0x6e
      	 ? __lock_acquire+0x268/0xf73
      	 ? rxrpc_connect+0xdd/0xe4
      	 ? __local_bh_enable_ip+0xb6/0xba
      	 __sys_sendmsg+0x5e/0x94
      	 do_syscall_64+0x7d/0x1bf
      	 entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 2341e077 ("rxrpc: Simplify connect() implementation and simplify sendmsg() op")
      Reported-by: syzbot+7966f2a0b2c7da8939b4@syzkaller.appspotmail.com
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bfa79135
    • AlbinYang's avatar
      nfc: fix potential illegal memory access · 97739e5c
      AlbinYang 提交于
      [ Upstream commit dd006fc434e107ef90f7de0db9907cbc1c521645 ]
      
      The frags_q is not properly initialized, it may result in illegal memory
      access when conn_info is NULL.
      The "goto free_exit" should be replaced by "goto exit".
      Signed-off-by: AlbinYang's avatarYang Wei <albin_yang@163.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97739e5c
    • J
      net: openvswitch: fix csum updates for MPLS actions · c60bce64
      John Hurley 提交于
      [ Upstream commit 0e3183cd2a64843a95b62f8bd4a83605a4cf0615 ]
      
      Skbs may have their checksum value populated by HW. If this is a checksum
      calculated over the entire packet then the CHECKSUM_COMPLETE field is
      marked. Changes to the data pointer on the skb throughout the network
      stack still try to maintain this complete csum value if it is required
      through functions such as skb_postpush_rcsum.
      
      The MPLS actions in Open vSwitch modify a CHECKSUM_COMPLETE value when
      changes are made to packet data without a push or a pull. This occurs when
      the ethertype of the MAC header is changed or when MPLS lse fields are
      modified.
      
      The modification is carried out using the csum_partial function to get the
      csum of a buffer and add it into the larger checksum. The buffer is an
      inversion of the data to be removed followed by the new data. Because the
      csum is calculated over 16 bits and these values align with 16 bits, the
      effect is the removal of the old value from the CHECKSUM_COMPLETE and
      addition of the new value.
      
      However, the csum fed into the function and the outcome of the
      calculation are also inverted. This would only make sense if it was the
      new value rather than the old that was inverted in the input buffer.
      
      Fix the issue by removing the bit inverts in the csum_partial calculation.
      
      The bug was verified and the fix tested by comparing the folded value of
      the updated CHECKSUM_COMPLETE value with the folded value of a full
      software checksum calculation (reset skb->csum to 0 and run
      skb_checksum_complete(skb)). Prior to the fix the outcomes differed but
      after they produce the same result.
      
      Fixes: 25cd9ba0 ("openvswitch: Add basic MPLS support to kernel")
      Fixes: bc7cc599 ("openvswitch: update checksum in {push,pop}_mpls")
      Signed-off-by: NJohn Hurley <john.hurley@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Acked-by: NPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c60bce64
    • L
      net: neigh: fix multiple neigh timer scheduling · 257441a0
      Lorenzo Bianconi 提交于
      [ Upstream commit 071c37983d99da07797294ea78e9da1a6e287144 ]
      
      Neigh timer can be scheduled multiple times from userspace adding
      multiple neigh entries and forcing the neigh timer scheduling passing
      NTF_USE in the netlink requests.
      This will result in a refcount leak and in the following dump stack:
      
      [   32.465295] NEIGH: BUG, double timer add, state is 8
      [   32.465308] CPU: 0 PID: 416 Comm: double_timer_ad Not tainted 5.2.0+ #65
      [   32.465311] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-2.fc30 04/01/2014
      [   32.465313] Call Trace:
      [   32.465318]  dump_stack+0x7c/0xc0
      [   32.465323]  __neigh_event_send+0x20c/0x880
      [   32.465326]  ? ___neigh_create+0x846/0xfb0
      [   32.465329]  ? neigh_lookup+0x2a9/0x410
      [   32.465332]  ? neightbl_fill_info.constprop.0+0x800/0x800
      [   32.465334]  neigh_add+0x4f8/0x5e0
      [   32.465337]  ? neigh_xmit+0x620/0x620
      [   32.465341]  ? find_held_lock+0x85/0xa0
      [   32.465345]  rtnetlink_rcv_msg+0x204/0x570
      [   32.465348]  ? rtnl_dellink+0x450/0x450
      [   32.465351]  ? mark_held_locks+0x90/0x90
      [   32.465354]  ? match_held_lock+0x1b/0x230
      [   32.465357]  netlink_rcv_skb+0xc4/0x1d0
      [   32.465360]  ? rtnl_dellink+0x450/0x450
      [   32.465363]  ? netlink_ack+0x420/0x420
      [   32.465366]  ? netlink_deliver_tap+0x115/0x560
      [   32.465369]  ? __alloc_skb+0xc9/0x2f0
      [   32.465372]  netlink_unicast+0x270/0x330
      [   32.465375]  ? netlink_attachskb+0x2f0/0x2f0
      [   32.465378]  netlink_sendmsg+0x34f/0x5a0
      [   32.465381]  ? netlink_unicast+0x330/0x330
      [   32.465385]  ? move_addr_to_kernel.part.0+0x20/0x20
      [   32.465388]  ? netlink_unicast+0x330/0x330
      [   32.465391]  sock_sendmsg+0x91/0xa0
      [   32.465394]  ___sys_sendmsg+0x407/0x480
      [   32.465397]  ? copy_msghdr_from_user+0x200/0x200
      [   32.465401]  ? _raw_spin_unlock_irqrestore+0x37/0x40
      [   32.465404]  ? lockdep_hardirqs_on+0x17d/0x250
      [   32.465407]  ? __wake_up_common_lock+0xcb/0x110
      [   32.465410]  ? __wake_up_common+0x230/0x230
      [   32.465413]  ? netlink_bind+0x3e1/0x490
      [   32.465416]  ? netlink_setsockopt+0x540/0x540
      [   32.465420]  ? __fget_light+0x9c/0xf0
      [   32.465423]  ? sockfd_lookup_light+0x8c/0xb0
      [   32.465426]  __sys_sendmsg+0xa5/0x110
      [   32.465429]  ? __ia32_sys_shutdown+0x30/0x30
      [   32.465432]  ? __fd_install+0xe1/0x2c0
      [   32.465435]  ? lockdep_hardirqs_off+0xb5/0x100
      [   32.465438]  ? mark_held_locks+0x24/0x90
      [   32.465441]  ? do_syscall_64+0xf/0x270
      [   32.465444]  do_syscall_64+0x63/0x270
      [   32.465448]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fix the issue unscheduling neigh_timer if selected entry is in 'IN_TIMER'
      receiving a netlink request with NTF_USE flag set
      Reported-by: NMarek Majkowski <marek@cloudflare.com>
      Fixes: 0c5c2d30 ("neigh: Allow for user space users of the neighbour table")
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      257441a0
    • F
      net: make skb_dst_force return true when dst is refcounted · 832d0ea7
      Florian Westphal 提交于
      [ Upstream commit b60a77386b1d4868f72f6353d35dabe5fbe981f2 ]
      
      netfilter did not expect that skb_dst_force() can cause skb to lose its
      dst entry.
      
      I got a bug report with a skb->dst NULL dereference in netfilter
      output path.  The backtrace contains nf_reinject(), so the dst might have
      been cleared when skb got queued to userspace.
      
      Other users were fixed via
      if (skb_dst(skb)) {
      	skb_dst_force(skb);
      	if (!skb_dst(skb))
      		goto handle_err;
      }
      
      But I think its preferable to make the 'dst might be cleared' part
      of the function explicit.
      
      In netfilter case, skb with a null dst is expected when queueing in
      prerouting hook, so drop skb for the other hooks.
      
      v2:
       v1 of this patch returned true in case skb had no dst entry.
       Eric said:
         Say if we have two skb_dst_force() calls for some reason
         on the same skb, only the first one will return false.
      
       This now returns false even when skb had no dst, as per Erics
       suggestion, so callers might need to check skb_dst() first before
       skb_dst_force().
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      832d0ea7
    • I
      ipv6: Unlink sibling route in case of failure · c0f4a644
      Ido Schimmel 提交于
      [ Upstream commit 54851aa90cf27041d64b12f65ac72e9f97bd90fd ]
      
      When a route needs to be appended to an existing multipath route,
      fib6_add_rt2node() first appends it to the siblings list and increments
      the number of sibling routes on each sibling.
      
      Later, the function notifies the route via call_fib6_entry_notifiers().
      In case the notification is vetoed, the route is not unlinked from the
      siblings list, which can result in a use-after-free.
      
      Fix this by unlinking the route from the siblings list before returning
      an error.
      
      Audited the rest of the call sites from which the FIB notification chain
      is called and could not find more problems.
      
      Fixes: 2233000c ("net/ipv6: Move call_fib6_entry_notifiers up for route adds")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NAlexander Petrovskiy <alexpe@mellanox.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0f4a644
    • D
      ipv6: rt6_check should return NULL if 'from' is NULL · 0bd84505
      David Ahern 提交于
      [ Upstream commit 49d05fe2c9d1b4a27761c9807fec39b8155bef9e ]
      
      Paul reported that l2tp sessions were broken after the commit referenced
      in the Fixes tag. Prior to this commit rt6_check returned NULL if the
      rt6_info 'from' was NULL - ie., the dst_entry was disconnected from a FIB
      entry. Restore that behavior.
      
      Fixes: 93531c67 ("net/ipv6: separate handling of FIB entries from dst based routes")
      Reported-by: NPaul Donohue <linux-kernel@PaulSD.com>
      Tested-by: NPaul Donohue <linux-kernel@PaulSD.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0bd84505
    • M
      ipv4: don't set IPv6 only flags to IPv4 addresses · 47ce4427
      Matteo Croce 提交于
      [ Upstream commit 2e60546368165c2449564d71f6005dda9205b5fb ]
      
      Avoid the situation where an IPV6 only flag is applied to an IPv4 address:
      
          # ip addr add 192.0.2.1/24 dev dummy0 nodad home mngtmpaddr noprefixroute
          # ip -4 addr show dev dummy0
          2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
              inet 192.0.2.1/24 scope global noprefixroute dummy0
                 valid_lft forever preferred_lft forever
      
      Or worse, by sending a malicious netlink command:
      
          # ip -4 addr show dev dummy0
          2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
              inet 192.0.2.1/24 scope global nodad optimistic dadfailed home tentative mngtmpaddr noprefixroute stable-privacy dummy0
                 valid_lft forever preferred_lft forever
      Signed-off-by: NMatteo Croce <mcroce@redhat.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47ce4427
    • E
      igmp: fix memory leak in igmpv3_del_delrec() · aee5dd00
      Eric Dumazet 提交于
      [ Upstream commit e5b1c6c6277d5a283290a8c033c72544746f9b5b ]
      
      im->tomb and/or im->sources might not be NULL, but we
      currently overwrite their values blindly.
      
      Using swap() will make sure the following call to kfree_pmc(pmc)
      will properly free the psf structures.
      
      Tested with the C repro provided by syzbot, which basically does :
      
       socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
       setsockopt(3, SOL_IP, IP_ADD_MEMBERSHIP, "\340\0\0\2\177\0\0\1\0\0\0\0", 12) = 0
       ioctl(3, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=0}) = 0
       setsockopt(3, SOL_IP, IP_MSFILTER, "\340\0\0\2\177\0\0\1\1\0\0\0\1\0\0\0\377\377\377\377", 20) = 0
       ioctl(3, SIOCSIFFLAGS, {ifr_name="lo", ifr_flags=IFF_UP}) = 0
       exit_group(0)                    = ?
      
      BUG: memory leak
      unreferenced object 0xffff88811450f140 (size 64):
        comm "softirq", pid 0, jiffies 4294942448 (age 32.070s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  ................
          00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000c7bad083>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
          [<00000000c7bad083>] slab_post_alloc_hook mm/slab.h:439 [inline]
          [<00000000c7bad083>] slab_alloc mm/slab.c:3326 [inline]
          [<00000000c7bad083>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
          [<000000009acc4151>] kmalloc include/linux/slab.h:547 [inline]
          [<000000009acc4151>] kzalloc include/linux/slab.h:742 [inline]
          [<000000009acc4151>] ip_mc_add1_src net/ipv4/igmp.c:1976 [inline]
          [<000000009acc4151>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2100
          [<000000004ac14566>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2484
          [<0000000052d8f995>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:959
          [<000000004ee1e21f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1248
          [<0000000066cdfe74>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2618
          [<000000009383a786>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3126
          [<00000000d8ac0c94>] __sys_setsockopt+0x98/0x120 net/socket.c:2072
          [<000000001b1e9666>] __do_sys_setsockopt net/socket.c:2083 [inline]
          [<000000001b1e9666>] __se_sys_setsockopt net/socket.c:2080 [inline]
          [<000000001b1e9666>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2080
          [<00000000420d395e>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
          [<000000007fd83a4b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 24803f38 ("igmp: do not remove igmp souce list info when set link down")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Hangbin Liu <liuhangbin@gmail.com>
      Reported-by: syzbot+6ca1abd0db68b5173a4f@syzkaller.appspotmail.com
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aee5dd00
  5. 26 7月, 2019 11 次提交
    • S
      Bluetooth: Add SMP workaround Microsoft Surface Precision Mouse bug · 152ddf9f
      Szymon Janc 提交于
      commit 1d87b88ba26eabd4745e158ecfd87c93a9b51dc2 upstream.
      
      Microsoft Surface Precision Mouse provides bogus identity address when
      pairing. It connects with Static Random address but provides Public
      Address in SMP Identity Address Information PDU. Address has same
      value but type is different. Workaround this by dropping IRK if ID
      address discrepancy is detected.
      
      > HCI Event: LE Meta Event (0x3e) plen 19
            LE Connection Complete (0x01)
              Status: Success (0x00)
              Handle: 75
              Role: Master (0x00)
              Peer address type: Random (0x01)
              Peer address: E0:52:33:93:3B:21 (Static)
              Connection interval: 50.00 msec (0x0028)
              Connection latency: 0 (0x0000)
              Supervision timeout: 420 msec (0x002a)
              Master clock accuracy: 0x00
      
      ....
      
      > ACL Data RX: Handle 75 flags 0x02 dlen 12
            SMP: Identity Address Information (0x09) len 7
              Address type: Public (0x00)
              Address: E0:52:33:93:3B:21
      Signed-off-by: NSzymon Janc <szymon.janc@codecoup.pl>
      Tested-by: NMaarten Fonville <maarten.fonville@gmail.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199461
      Cc: stable@vger.kernel.org
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      152ddf9f
    • Y
      9p/virtio: Add cleanup path in p9_virtio_init · b52807e6
      YueHaibing 提交于
      commit d4548543fc4ece56c6f04b8586f435fb4fd84c20 upstream.
      
      KASAN report this:
      
      BUG: unable to handle kernel paging request at ffffffffa0097000
      PGD 3870067 P4D 3870067 PUD 3871063 PMD 2326e2067 PTE 0
      Oops: 0000 [#1
      CPU: 0 PID: 5340 Comm: modprobe Not tainted 5.1.0-rc7+ #25
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
      RIP: 0010:__list_add_valid+0x10/0x70
      Code: c3 48 8b 06 55 48 89 e5 5d 48 39 07 0f 94 c0 0f b6 c0 c3 90 90 90 90 90 90 90 55 48 89 d0 48 8b 52 08 48 89 e5 48 39 f2 75 19 <48> 8b 32 48 39 f0 75 3a
      
      RSP: 0018:ffffc90000e23c68 EFLAGS: 00010246
      RAX: ffffffffa00ad000 RBX: ffffffffa009d000 RCX: 0000000000000000
      RDX: ffffffffa0097000 RSI: ffffffffa0097000 RDI: ffffffffa009d000
      RBP: ffffc90000e23c68 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa0097000
      R13: ffff888231797180 R14: 0000000000000000 R15: ffffc90000e23e78
      FS:  00007fb215285540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffa0097000 CR3: 000000022f144000 CR4: 00000000000006f0
      Call Trace:
       v9fs_register_trans+0x2f/0x60 [9pnet
       ? 0xffffffffa0087000
       p9_virtio_init+0x25/0x1000 [9pnet_virtio
       do_one_initcall+0x6c/0x3cc
       ? kmem_cache_alloc_trace+0x248/0x3b0
       do_init_module+0x5b/0x1f1
       load_module+0x1db1/0x2690
       ? m_show+0x1d0/0x1d0
       __do_sys_finit_module+0xc5/0xd0
       __x64_sys_finit_module+0x15/0x20
       do_syscall_64+0x6b/0x1d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7fb214d8e839
      Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01
      
      RSP: 002b:00007ffc96554278 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000055e67eed2aa0 RCX: 00007fb214d8e839
      RDX: 0000000000000000 RSI: 000055e67ce95c2e RDI: 0000000000000003
      RBP: 000055e67ce95c2e R08: 0000000000000000 R09: 000055e67eed2aa0
      R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
      R13: 000055e67eeda500 R14: 0000000000040000 R15: 000055e67eed2aa0
      Modules linked in: 9pnet_virtio(+) 9pnet gre rfkill vmw_vsock_virtio_transport_common vsock [last unloaded: 9pnet_virtio
      CR2: ffffffffa0097000
      ---[ end trace 4a52bb13ff07b761
      
      If register_virtio_driver() fails in p9_virtio_init,
      we should call v9fs_unregister_trans() to do cleanup.
      
      Link: http://lkml.kernel.org/r/20190430115942.41840-1-yuehaibing@huawei.com
      Cc: stable@vger.kernel.org
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Fixes: b530cc79 ("9p: add virtio transport")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b52807e6
    • Y
      9p/xen: Add cleanup path in p9_trans_xen_init · 1253882d
      YueHaibing 提交于
      commit 80a316ff16276b36d0392a8f8b2f63259857ae98 upstream.
      
      If xenbus_register_frontend() fails in p9_trans_xen_init,
      we should call v9fs_unregister_trans() to do cleanup.
      
      Link: http://lkml.kernel.org/r/20190430143933.19368-1-yuehaibing@huawei.com
      Cc: stable@vger.kernel.org
      Fixes: 868eb122 ("xen/9pfs: introduce Xen 9pfs transport driver")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1253882d
    • C
      Bluetooth: validate BLE connection interval updates · 202de90d
      csonsino 提交于
      [ Upstream commit c49a8682fc5d298d44e8d911f4fa14690ea9485e ]
      
      Problem: The Linux Bluetooth stack yields complete control over the BLE
      connection interval to the remote device.
      
      The Linux Bluetooth stack provides access to the BLE connection interval
      min and max values through /sys/kernel/debug/bluetooth/hci0/
      conn_min_interval and /sys/kernel/debug/bluetooth/hci0/conn_max_interval.
      These values are used for initial BLE connections, but the remote device
      has the ability to request a connection parameter update. In the event
      that the remote side requests to change the connection interval, the Linux
      kernel currently only validates that the desired value is within the
      acceptable range in the Bluetooth specification (6 - 3200, corresponding to
      7.5ms - 4000ms). There is currently no validation that the desired value
      requested by the remote device is within the min/max limits specified in
      the conn_min_interval/conn_max_interval configurations. This essentially
      leads to Linux yielding complete control over the connection interval to
      the remote device.
      
      The proposed patch adds a verification step to the connection parameter
      update mechanism, ensuring that the desired value is within the min/max
      bounds of the current connection. If the desired value is outside of the
      current connection min/max values, then the connection parameter update
      request is rejected and the negative response is returned to the remote
      device. Recall that the initial connection is established using the local
      conn_min_interval/conn_max_interval values, so this allows the Linux
      administrator to retain control over the BLE connection interval.
      
      The one downside that I see is that the current default Linux values for
      conn_min_interval and conn_max_interval typically correspond to 30ms and
      50ms respectively. If this change were accepted, then it is feasible that
      some devices would no longer be able to negotiate to their desired
      connection interval values. This might be remedied by setting the default
      Linux conn_min_interval and conn_max_interval values to the widest
      supported range (6 - 3200 / 7.5ms - 4000ms). This could lead to the same
      behavior as the current implementation, where the remote device could
      request to change the connection interval value to any value that is
      permitted by the Bluetooth specification, and Linux would accept the
      desired value.
      Signed-off-by: NCarey Sonsino <csonsino@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      202de90d
    • M
      Bluetooth: Check state in l2cap_disconnect_rsp · 0fdb922d
      Matias Karhumaa 提交于
      [ Upstream commit 28261da8a26f4915aa257d12d506c6ba179d961f ]
      
      Because of both sides doing L2CAP disconnection at the same time, it
      was possible to receive L2CAP Disconnection Response with CID that was
      already freed. That caused problems if CID was already reused and L2CAP
      Connection Request with same CID was sent out. Before this patch kernel
      deleted channel context regardless of the state of the channel.
      
      Example where leftover Disconnection Response (frame #402) causes local
      device to delete L2CAP channel which was not yet connected. This in
      turn confuses remote device's stack because same CID is re-used without
      properly disconnecting.
      
      Btmon capture before patch:
      ** snip **
      > ACL Data RX: Handle 43 flags 0x02 dlen 8                #394 [hci1] 10.748949
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8                #395 [hci1] 10.749062
            Channel: 65 len 4 [PSM 3 mode 0] {chan 2}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #396 [hci1] 10.749073
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Packets (0x13) plen 5    #397 [hci1] 10.752391
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Packets (0x13) plen 5    #398 [hci1] 10.753394
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #399 [hci1] 10.756499
            L2CAP: Disconnection Request (0x06) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #400 [hci1] 10.756548
            L2CAP: Disconnection Response (0x07) ident 26 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12               #401 [hci1] 10.757459
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #402 [hci1] 10.759148
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      = bluetoothd: 00:1E:AB:4C:56:54: error updating services: Input/o..   10.759447
      > HCI Event: Number of Completed Packets (0x13) plen 5    #403 [hci1] 10.759386
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12               #404 [hci1] 10.760397
            L2CAP: Connection Request (0x02) ident 27 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16               #405 [hci1] 10.760441
            L2CAP: Connection Response (0x03) ident 27 len 8
              Destination CID: 65
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27               #406 [hci1] 10.760449
            L2CAP: Configure Request (0x04) ident 19 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > HCI Event: Number of Completed Packets (0x13) plen 5    #407 [hci1] 10.761399
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 16               #408 [hci1] 10.762942
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Similar case after the patch:
      *snip*
      > ACL Data RX: Handle 43 flags 0x02 dlen 8            #22702 [hci0] 1664.411056
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Disconnect (DISC) (0x43)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x53 poll/final 1
               Length: 0
               FCS: 0xfd
      < ACL Data TX: Handle 43 flags 0x00 dlen 8            #22703 [hci0] 1664.411136
            Channel: 65 len 4 [PSM 3 mode 0] {chan 3}
            RFCOMM: Unnumbered Ack (UA) (0x63)
               Address: 0x03 cr 1 dlci 0x00
               Control: 0x73 poll/final 1
               Length: 0
               FCS: 0xd7
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22704 [hci0] 1664.411143
            L2CAP: Disconnection Request (0x06) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22705 [hci0] 1664.414009
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22706 [hci0] 1664.415007
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22707 [hci0] 1664.418674
            L2CAP: Disconnection Request (0x06) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22708 [hci0] 1664.418762
            L2CAP: Disconnection Response (0x07) ident 17 len 4
              Destination CID: 65
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 12           #22709 [hci0] 1664.421073
            L2CAP: Connection Request (0x02) ident 12 len 4
              PSM: 1 (0x0001)
              Source CID: 65
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22710 [hci0] 1664.421371
            L2CAP: Disconnection Response (0x07) ident 11 len 4
              Destination CID: 65
              Source CID: 65
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22711 [hci0] 1664.424082
              Num handles: 1
              Handle: 43
              Count: 1
      > HCI Event: Number of Completed Pac.. (0x13) plen 5  #22712 [hci0] 1664.425040
              Num handles: 1
              Handle: 43
              Count: 1
      > ACL Data RX: Handle 43 flags 0x02 dlen 12           #22713 [hci0] 1664.426103
            L2CAP: Connection Request (0x02) ident 18 len 4
              PSM: 3 (0x0003)
              Source CID: 65
      < ACL Data TX: Handle 43 flags 0x00 dlen 16           #22714 [hci0] 1664.426186
            L2CAP: Connection Response (0x03) ident 18 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      < ACL Data TX: Handle 43 flags 0x00 dlen 27           #22715 [hci0] 1664.426196
            L2CAP: Configure Request (0x04) ident 13 len 19
              Destination CID: 65
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 1013
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Basic (0x00)
                TX window size: 0
                Max transmit: 0
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 0
      > ACL Data RX: Handle 43 flags 0x02 dlen 16           #22716 [hci0] 1664.428804
            L2CAP: Connection Response (0x03) ident 12 len 8
              Destination CID: 66
              Source CID: 65
              Result: Connection successful (0x0000)
              Status: No further information available (0x0000)
      *snip*
      
      Fix is to check that channel is in state BT_DISCONN before deleting the
      channel.
      
      This bug was found while fuzzing Bluez's OBEX implementation using
      Synopsys Defensics.
      Reported-by: NMatti Kamunen <matti.kamunen@synopsys.com>
      Reported-by: NAri Timonen <ari.timonen@synopsys.com>
      Signed-off-by: NMatias Karhumaa <matias.karhumaa@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0fdb922d
    • J
      Bluetooth: 6lowpan: search for destination address in all peers · c814f618
      Josua Mayer 提交于
      [ Upstream commit b188b03270b7f8568fc714101ce82fbf5e811c5a ]
      
      Handle overlooked case where the target address is assigned to a peer
      and neither route nor gateway exist.
      
      For one peer, no checks are performed to see if it is meant to receive
      packets for a given address.
      
      As soon as there is a second peer however, checks are performed
      to deal with routes and gateways for handling complex setups with
      multiple hops to a target address.
      This logic assumed that no route and no gateway imply that the
      destination address can not be reached, which is false in case of a
      direct peer.
      Acked-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
      Tested-by: NMichael Scott <mike@foundries.io>
      Signed-off-by: NJosua Mayer <josua.mayer@jm0.eu>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c814f618
    • N
      xsk: Properly terminate assignment in xskq_produce_flush_desc · dad0b17e
      Nathan Chancellor 提交于
      [ Upstream commit f7019b7b0ad14bde732b8953161994edfc384953 ]
      
      Clang warns:
      
      In file included from net/xdp/xsk_queue.c:10:
      net/xdp/xsk_queue.h:292:2: warning: expression result unused
      [-Wunused-value]
              WRITE_ONCE(q->ring->producer, q->prod_tail);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      include/linux/compiler.h:284:6: note: expanded from macro 'WRITE_ONCE'
              __u.__val;                                      \
              ~~~ ^~~~~
      1 warning generated.
      
      The q->prod_tail assignment has a comma at the end, not a semi-colon.
      Fix that so clang no longer warns and everything works as expected.
      
      Fixes: c497176c ("xsk: add Rx receive functions and poll support")
      Link: https://github.com/ClangBuiltLinux/linux/issues/544Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Acked-by: NNick Desaulniers <ndesaulniers@google.com>
      Acked-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Acked-by: NBjörn Töpel <bjorn.topel@intel.com>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dad0b17e
    • J
      ipvs: fix tinfo memory leak in start_sync_thread · fe2ceeb4
      Julian Anastasov 提交于
      [ Upstream commit 5db7c8b9f9fc2aeec671ae3ca6375752c162e0e7 ]
      
      syzkaller reports for memory leak in start_sync_thread [1]
      
      As Eric points out, kthread may start and stop before the
      threadfn function is called, so there is no chance the
      data (tinfo in our case) to be released in thread.
      
      Fix this by releasing tinfo in the controlling code instead.
      
      [1]
      BUG: memory leak
      unreferenced object 0xffff8881206bf700 (size 32):
       comm "syz-executor761", pid 7268, jiffies 4294943441 (age 20.470s)
       hex dump (first 32 bytes):
         00 40 7c 09 81 88 ff ff 80 45 b8 21 81 88 ff ff  .@|......E.!....
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       backtrace:
         [<0000000057619e23>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
         [<0000000057619e23>] slab_post_alloc_hook mm/slab.h:439 [inline]
         [<0000000057619e23>] slab_alloc mm/slab.c:3326 [inline]
         [<0000000057619e23>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
         [<0000000086ce5479>] kmalloc include/linux/slab.h:547 [inline]
         [<0000000086ce5479>] start_sync_thread+0x5d2/0xe10 net/netfilter/ipvs/ip_vs_sync.c:1862
         [<000000001a9229cc>] do_ip_vs_set_ctl+0x4c5/0x780 net/netfilter/ipvs/ip_vs_ctl.c:2402
         [<00000000ece457c8>] nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
         [<00000000ece457c8>] nf_setsockopt+0x4c/0x80 net/netfilter/nf_sockopt.c:115
         [<00000000942f62d4>] ip_setsockopt net/ipv4/ip_sockglue.c:1258 [inline]
         [<00000000942f62d4>] ip_setsockopt+0x9b/0xb0 net/ipv4/ip_sockglue.c:1238
         [<00000000a56a8ffd>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
         [<00000000fa895401>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130
         [<0000000095eef4cf>] __sys_setsockopt+0x98/0x120 net/socket.c:2078
         [<000000009747cf88>] __do_sys_setsockopt net/socket.c:2089 [inline]
         [<000000009747cf88>] __se_sys_setsockopt net/socket.c:2086 [inline]
         [<000000009747cf88>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
         [<00000000ded8ba80>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
         [<00000000893b4ac8>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Reported-by: syzbot+7e2e50c8adfccd2e5041@syzkaller.appspotmail.com
      Suggested-by: NEric Biggers <ebiggers@kernel.org>
      Fixes: 998e7a76 ("ipvs: Use kthread_run() instead of doing a double-fork via kernel_thread()")
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Acked-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fe2ceeb4
    • J
      ipvs: defer hook registration to avoid leaks · 57de3c78
      Julian Anastasov 提交于
      [ Upstream commit cf47a0b882a4e5f6b34c7949d7b293e9287f1972 ]
      
      syzkaller reports for memory leak when registering hooks [1]
      
      As we moved the nf_unregister_net_hooks() call into
      __ip_vs_dev_cleanup(), defer the nf_register_net_hooks()
      call, so that hooks are allocated and freed from same
      pernet_operations (ipvs_core_dev_ops).
      
      [1]
      BUG: memory leak
      unreferenced object 0xffff88810acd8a80 (size 96):
       comm "syz-executor073", pid 7254, jiffies 4294950560 (age 22.250s)
       hex dump (first 32 bytes):
         02 00 00 00 00 00 00 00 50 8b bb 82 ff ff ff ff  ........P.......
         00 00 00 00 00 00 00 00 00 77 bb 82 ff ff ff ff  .........w......
       backtrace:
         [<0000000013db61f1>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
         [<0000000013db61f1>] slab_post_alloc_hook mm/slab.h:439 [inline]
         [<0000000013db61f1>] slab_alloc_node mm/slab.c:3269 [inline]
         [<0000000013db61f1>] kmem_cache_alloc_node_trace+0x15b/0x2a0 mm/slab.c:3597
         [<000000001a27307d>] __do_kmalloc_node mm/slab.c:3619 [inline]
         [<000000001a27307d>] __kmalloc_node+0x38/0x50 mm/slab.c:3627
         [<0000000025054add>] kmalloc_node include/linux/slab.h:590 [inline]
         [<0000000025054add>] kvmalloc_node+0x4a/0xd0 mm/util.c:431
         [<0000000050d1bc00>] kvmalloc include/linux/mm.h:637 [inline]
         [<0000000050d1bc00>] kvzalloc include/linux/mm.h:645 [inline]
         [<0000000050d1bc00>] allocate_hook_entries_size+0x3b/0x60 net/netfilter/core.c:61
         [<00000000e8abe142>] nf_hook_entries_grow+0xae/0x270 net/netfilter/core.c:128
         [<000000004b94797c>] __nf_register_net_hook+0x9a/0x170 net/netfilter/core.c:337
         [<00000000d1545cbc>] nf_register_net_hook+0x34/0xc0 net/netfilter/core.c:464
         [<00000000876c9b55>] nf_register_net_hooks+0x53/0xc0 net/netfilter/core.c:480
         [<000000002ea868e0>] __ip_vs_init+0xe8/0x170 net/netfilter/ipvs/ip_vs_core.c:2280
         [<000000002eb2d451>] ops_init+0x4c/0x140 net/core/net_namespace.c:130
         [<000000000284ec48>] setup_net+0xde/0x230 net/core/net_namespace.c:316
         [<00000000a70600fa>] copy_net_ns+0xf0/0x1e0 net/core/net_namespace.c:439
         [<00000000ff26c15e>] create_new_namespaces+0x141/0x2a0 kernel/nsproxy.c:107
         [<00000000b103dc79>] copy_namespaces+0xa1/0xe0 kernel/nsproxy.c:165
         [<000000007cc008a2>] copy_process.part.0+0x11fd/0x2150 kernel/fork.c:2035
         [<00000000c344af7c>] copy_process kernel/fork.c:1800 [inline]
         [<00000000c344af7c>] _do_fork+0x121/0x4f0 kernel/fork.c:2369
      
      Reported-by: syzbot+722da59ccb264bc19910@syzkaller.appspotmail.com
      Fixes: 719c7d563c17 ("ipvs: Fix use-after-free in ip_vs_in")
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Acked-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      57de3c78
    • A
      ipsec: select crypto ciphers for xfrm_algo · 06a3cd41
      Arnd Bergmann 提交于
      [ Upstream commit 597179b0ba550bd83fab1a9d57c42a9343c58514 ]
      
      kernelci.org reports failed builds on arc because of what looks
      like an old missed 'select' statement:
      
      net/xfrm/xfrm_algo.o: In function `xfrm_probe_algs':
      xfrm_algo.c:(.text+0x1e8): undefined reference to `crypto_has_ahash'
      
      I don't see this in randconfig builds on other architectures, but
      it's fairly clear we want to select the hash code for it, like we
      do for all its other users. As Herbert points out, CRYPTO_BLKCIPHER
      is also required even though it has not popped up in build tests.
      
      Fixes: 17bc1970 ("ipsec: Use skcipher and ahash when probing algorithms")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      06a3cd41
    • N
      xfrm: fix sa selector validation · 930655b0
      Nicolas Dichtel 提交于
      [ Upstream commit b8d6d0079757cbd1b69724cfd1c08e2171c68cee ]
      
      After commit b38ff4075a80, the following command does not work anymore:
      $ ip xfrm state add src 10.125.0.2 dst 10.125.0.1 proto esp spi 34 reqid 1 \
        mode tunnel enc 'cbc(aes)' 0xb0abdba8b782ad9d364ec81e3a7d82a1 auth-trunc \
        'hmac(sha1)' 0xe26609ebd00acb6a4d51fca13e49ea78a72c73e6 96 flag align4
      
      In fact, the selector is not mandatory, allow the user to provide an empty
      selector.
      
      Fixes: b38ff4075a80 ("xfrm: Fix xfrm sel prefix length validation")
      CC: Anirudh Gupta <anirudh.gupta@sophos.com>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      930655b0