linux-kernel - Re: memory leak in ipv6_sock_ac

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <7f189d22226841168eb46b7be8939e2d06fa476c.camel@redhat.com>
Date:   Fri, 19 May 2023 16:46:42 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     范俊杰 <junjie2020@...as.ac.cn>,
        davem@...emloft.net, dsahern@...nel.org, edumazet@...gle.com,
        kuba@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     syzkaller-bugs@...glegroups.com
Subject: Re: memory leak in ipv6_sock_ac_join

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