netdev - Re: memory leak in tls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20201229110106.430c6859@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 29 Dec 2020 11:01:10 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     syzbot <syzbot+35bc8fe94c9f38db8320@...kaller.appspotmail.com>
Cc:     aviadye@...lanox.com, borisp@...lanox.com, daniel@...earbox.net,
        davejwatson@...com, davem@...emloft.net,
        jakub.kicinski@...ronome.com, john.fastabend@...il.com,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: memory leak in tls_init

On Thu, 26 Sep 2019 18:19:09 -0700 syzbot wrote:
> 2019/09/26 13:11:21 executed programs: 23
> BUG: memory leak
> unreferenced object 0xffff88810e482a00 (size 512):
>    comm "syz-executor.4", pid 6874, jiffies 4295090041 (age 14.090s)
>    hex dump (first 32 bytes):
>      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>    backtrace:
>      [<00000000e93f019a>] kmemleak_alloc_recursive  
> include/linux/kmemleak.h:43 [inline]
>      [<00000000e93f019a>] slab_post_alloc_hook mm/slab.h:586 [inline]
>      [<00000000e93f019a>] slab_alloc mm/slab.c:3319 [inline]
>      [<00000000e93f019a>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
>      [<00000000268637bd>] kmalloc include/linux/slab.h:552 [inline]
>      [<00000000268637bd>] kzalloc include/linux/slab.h:686 [inline]
>      [<00000000268637bd>] create_ctx net/tls/tls_main.c:611 [inline]
>      [<00000000268637bd>] tls_init net/tls/tls_main.c:794 [inline]
>      [<00000000268637bd>] tls_init+0xbc/0x200 net/tls/tls_main.c:773
>      [<00000000f52c33c5>] __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline]
>      [<00000000f52c33c5>] tcp_set_ulp+0xe2/0x190 net/ipv4/tcp_ulp.c:160
>      [<0000000009cb49a0>] do_tcp_setsockopt.isra.0+0x1c1/0xe10  
> net/ipv4/tcp.c:2825
>      [<00000000b9d96429>] tcp_setsockopt+0x71/0x80 net/ipv4/tcp.c:3152
>      [<0000000038a5546c>] sock_common_setsockopt+0x38/0x50  
> net/core/sock.c:3142
>      [<00000000d945b2a0>] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
>      [<000000003c3afaa0>] __do_sys_setsockopt net/socket.c:2100 [inline]
>      [<000000003c3afaa0>] __se_sys_setsockopt net/socket.c:2097 [inline]
>      [<000000003c3afaa0>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2097
>      [<00000000f7f21cbd>] do_syscall_64+0x73/0x1f0  
> arch/x86/entry/common.c:290
>      [<00000000d4c003b9>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

#syz invalid

This hasn't happened for over a year, so perhaps the TOE-related
restructuring accidentally fixed it, somehow.