From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C38C3C7618B for ; Wed, 24 Jul 2019 10:47:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8D540229ED for ; Wed, 24 Jul 2019 10:47:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727137AbfGXKrD (ORCPT ); Wed, 24 Jul 2019 06:47:03 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:45410 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726087AbfGXKrD (ORCPT ); Wed, 24 Jul 2019 06:47:03 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id B6D1D7B848989C48A984; Wed, 24 Jul 2019 18:47:00 +0800 (CST) Received: from [127.0.0.1] (10.177.96.96) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.439.0; Wed, 24 Jul 2019 18:46:56 +0800 Subject: Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit To: Eric Dumazet , , , , References: <20190724091715.137033-1-maowenan@huawei.com> <2e09f4d1-8a47-27e9-60f9-63d3b19a98ec@gmail.com> From: maowenan Message-ID: <13ffa2fe-d064-9786-bc52-e4281d26ed1d@huawei.com> Date: Wed, 24 Jul 2019 18:46:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2e09f4d1-8a47-27e9-60f9-63d3b19a98ec@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.96.96] X-CFilter-Loop: Reflected Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2019/7/24 17:45, Eric Dumazet wrote: > > > On 7/24/19 11:17 AM, Mao Wenan wrote: >> There is one report about tcp_write_xmit use-after-free with version 4.4.136: >> >> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline] >> BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline] >> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056 >> Read of size 2 at addr ffff8801d6fc87b0 by task syz-executor408/4195 >> >> CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 >> 0000000000000000 7d8f38ecc03be946 ffff8801d73b7710 ffffffff81e0edad >> ffffea00075bf200 ffff8801d6fc87b0 0000000000000000 ffff8801d6fc87b0 >> dffffc0000000000 ffff8801d73b7748 ffffffff815159b6 ffff8801d6fc87b0 >> Call Trace: >> [] __dump_stack lib/dump_stack.c:15 [inline] >> [] dump_stack+0xc1/0x124 lib/dump_stack.c:51 >> [] print_address_description+0x6c/0x216 mm/kasan/report.c:252 >> [] kasan_report_error mm/kasan/report.c:351 [inline] >> [] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408 >> [] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427 >> [] tcp_skb_pcount include/net/tcp.h:796 [inline] >> [] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline] >> [] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056 >> [] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307 >> [] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883 >> [] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112 >> [] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435 >> [] sock_release+0x96/0x1c0 net/socket.c:586 >> [] sock_close+0x16/0x20 net/socket.c:1037 >> [] __fput+0x235/0x6f0 fs/file_table.c:208 >> [] ____fput+0x15/0x20 fs/file_table.c:244 >> [] task_work_run+0x10f/0x190 kernel/task_work.c:115 >> [] exit_task_work include/linux/task_work.h:21 [inline] >> [] do_exit+0x9e5/0x26b0 kernel/exit.c:759 >> [] do_group_exit+0x111/0x330 kernel/exit.c:889 >> [] get_signal+0x4ec/0x14b0 kernel/signal.c:2321 >> [] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712 >> [] exit_to_usermode_loop+0x11a/0x160 arch/x86/entry/common.c:248 >> [] prepare_exit_to_usermode arch/x86/entry/common.c:283 [inline] >> [] syscall_return_slowpath+0x1b5/0x1f0 arch/x86/entry/common.c:348 >> [] int_ret_from_sys_call+0x25/0xa3 >> >> Allocated by task 4194: >> [] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63 >> [] save_stack+0x43/0xd0 mm/kasan/kasan.c:512 >> [] set_track mm/kasan/kasan.c:524 [inline] >> [] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616 >> [] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554 >> [] slab_post_alloc_hook mm/slub.c:1349 [inline] >> [] slab_alloc_node mm/slub.c:2615 [inline] >> [] slab_alloc mm/slub.c:2623 [inline] >> [] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628 >> [] kmem_cache_alloc_node include/linux/slab.h:350 [inline] >> [] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218 >> [] alloc_skb_fclone include/linux/skbuff.h:856 [inline] >> [] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833 >> [] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178 >> [] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755 >> [] sock_sendmsg_nosec net/socket.c:625 [inline] >> [] sock_sendmsg+0xcc/0x110 net/socket.c:635 >> [] SYSC_sendto+0x21c/0x370 net/socket.c:1665 >> [] SyS_sendto+0x40/0x50 net/socket.c:1633 >> [] entry_SYSCALL_64_fastpath+0x22/0x9e >> >> Freed by task 4194: >> [] save_stack_trace+0x26/0x50 arch/x86/kernel/stacktrace.c:63 >> [] save_stack+0x43/0xd0 mm/kasan/kasan.c:512 >> [] set_track mm/kasan/kasan.c:524 [inline] >> [] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589 >> [] slab_free_hook mm/slub.c:1383 [inline] >> [] slab_free_freelist_hook mm/slub.c:1405 [inline] >> [] slab_free mm/slub.c:2859 [inline] >> [] kmem_cache_free+0xbe/0x340 mm/slub.c:2881 >> [] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635 >> [] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676 >> [] sk_wmem_free_skb include/net/sock.h:1447 [inline] >> [] tcp_write_queue_purge include/net/tcp.h:1460 [inline] >> [] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline] >> [] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261 >> [] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246 >> [] __inet_stream_connect+0x2a9/0xc30 net/ipv4/af_inet.c:615 >> [] inet_stream_connect+0x55/0xa0 net/ipv4/af_inet.c:676 >> [] SYSC_connect+0x1b8/0x300 net/socket.c:1557 >> [] SyS_connect+0x24/0x30 net/socket.c:1538 >> [] entry_SYSCALL_64_fastpath+0x22/0x9e >> >> Syzkaller reproducer(): >> r0 = socket$packet(0x11, 0x3, 0x300) >> r1 = socket$inet_tcp(0x2, 0x1, 0x0) >> bind$inet(r1, &(0x7f0000000300)={0x2, 0x4e21, @multicast1}, 0x10) >> connect$inet(r1, &(0x7f0000000140)={0x2, 0x1000004e21, @loopback}, 0x10) >> recvmmsg(r1, &(0x7f0000001e40)=[{{0x0, 0x0, &(0x7f0000000100)=[{&(0x7f00000005c0)=""/88, 0x58}], 0x1}}], 0x1, 0x40000000, 0x0) >> sendto$inet(r1, &(0x7f0000000000)="e2f7ad5b661c761edf", 0x9, 0x8080, 0x0, 0x0) >> r2 = fcntl$dupfd(r1, 0x0, r0) >> connect$unix(r2, &(0x7f00000001c0)=@file={0x0, './file0\x00'}, 0x6e) >> >> C repro link: https://syzkaller.appspot.com/text?tag=ReproC&x=14db474f800000 >> >> This is because when tcp_connect_init call tcp_write_queue_purge, it will >> kfree all the skb in the write_queue, but the sk->sk_send_head forget to set NULL, >> then tcp_write_xmit try to send skb, which has freed in tcp_write_queue_purge, UAF happens. >> >> Signed-off-by: Mao Wenan >> --- >> include/net/tcp.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/include/net/tcp.h b/include/net/tcp.h >> index bf8a0dae977a..8f8aace28cf8 100644 >> --- a/include/net/tcp.h >> +++ b/include/net/tcp.h >> @@ -1457,6 +1457,7 @@ static inline void tcp_write_queue_purge(struct sock *sk) >> >> while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL) >> sk_wmem_free_skb(sk, skb); >> + sk->sk_send_head = NULL; >> sk_mem_reclaim(sk); >> tcp_clear_all_retrans_hints(tcp_sk(sk)); >> inet_csk(sk)->icsk_backoff = 0; >> > > This is strange, because tcp_init_send_head() is called from tcp_disconnect() > which is the syzkaller way to trigger this kind of bugs. > syzkaller reproduce program duplicate one socket that have multiple skb in write queue, and new socket have purged skb but original socket still try to send skb. In this program, it does not call tcp_disconnect? > > I suspect there is another root cause. > > > > . >