Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Subject: Re: memory leak in ipv6_sock_ac_join
From:   =?utf-8?B?6IyD5L+K5p2w?= <junjie2020@iscas.ac.cn>
In-Reply-To: <7f189d22226841168eb46b7be8939e2d06fa476c.camel@redhat.com>
Date:   Sat, 20 May 2023 12:43:07 +0800
Cc:     davem@davemloft.net, dsahern@kernel.org, edumazet@google.com,
        kuba@kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Content-Transfer-Encoding: 8BIT
Message-Id: <B4E62EDC-8364-4527-926D-6AFEFFB1D7B4@iscas.ac.cn>
References: <13e257b8.6869.18833286427.Coremail.junjie2020@iscas.ac.cn>
 <7f189d22226841168eb46b7be8939e2d06fa476c.camel@redhat.com>
To:     Paolo Abeni <pabeni@redhat.com>
Precedence: bulk

Thank you for your response. This is my first time submitting crashes to kernel developers, so forgive me if there are any shortcomings. In my opinion, some of the code crashes in the old version may also be present in the new version. That’s why I want to report these crash to you. I will take note of the issues you mentioned and make a meaningful contribution by submitting valid kernel errors next time.!
Sincerely!

> 2023年5月19日 22:46，Paolo Abeni <pabeni@redhat.com> 写道：
> 
> hi,
> 
> Please use plain-text when sending messages to a kernel devel mailing
> list.
> 
> On Fri, 2023-05-19 at 16:37 +0800, 范俊杰 wrote:
>> Our modified tool found a new bug BUG: unable to handle kernel NULL
>> pointer dereference in scsi_queue_rq 
> 
> What you mention above is different from what you actually reports
> below.
> 
>> in Kernel commit v5.14. 
> 
> That is not exactly new.
> 
>> The report is as below and this bug don't have a repro C program
>> until now. Please inform me if you confirm this is a reproducible
>> bug.
> 
> I think the above expectation is quite beyond what you could get. When
> you reports a bug _you_ are supposed to try to reproduce it.
> 
>>  ---
>>  BUG: memory leak
>> unreferenced object 0xffff8ad4e16c5760 (size 32):
>>   comm "syz-executor.2", pid 17137, jiffies 4295510146 (age 7.862s)
>>   hex dump (first 32 bytes):
>>     fe 80 00 00 00 00 00 00 00 00 00 00 00 00 00 bb  ................
>>     01 00 00 00 d4 8a ff ff 00 00 00 00 00 00 00 00  ................
>>   backtrace:
>>     [<00000000033cd1b4>] kmalloc include/linux/slab.h:605 [inline]
>>     [<00000000033cd1b4>] sock_kmalloc+0x48/0x80 net/core/sock.c:2563
>>     [<00000000724962dc>] ipv6_sock_ac_join+0xf0/0x2d0
>> net/ipv6/anycast.c:86
>>     [<0000000027291f90>] do_ipv6_setsockopt.isra.14+0x1e23/0x21a0
>> net/ipv6/ipv6_sockglue.c:868
>>     [<00000000bb6b5160>] ipv6_setsockopt+0xa9/0xf0
>> net/ipv6/ipv6_sockglue.c:1021
>>     [<0000000057fe6cc3>] udpv6_setsockopt+0x53/0xa0
>> net/ipv6/udp.c:1652
>>     [<0000000023dcd6bb>] __sys_setsockopt+0xb6/0x160
>> net/socket.c:2259
>>     [<0000000081a16a2e>] __do_sys_setsockopt net/socket.c:2270
>> [inline]
>>     [<0000000081a16a2e>] __se_sys_setsockopt net/socket.c:2267
>> [inline]
>>     [<0000000081a16a2e>] __x64_sys_setsockopt+0x22/0x30
>> net/socket.c:2267
>>     [<0000000075aec224>] do_syscall_x64 arch/x86/entry/common.c:50
>> [inline]
>>     [<0000000075aec224>] do_syscall_64+0x37/0x80
>> arch/x86/entry/common.c:80
>>     [<000000006cd4d12f>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
>> 
>> BUG: leak checking failed
> 
> This was probably addressed by:
> 
> 8c0de6e96c97 ("ipv6: fix memory leaks on IPV6_ADDRFORM path") 
> 
> 
> Cheers,
> 
> Paolo