[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dffd88ff-57c8-40b1-a02e-499d71f2986c@miraclelinux.com>
Date: Wed, 3 Jul 2024 15:45:09 +0900
From: Kazunori Kobayashi <kazunori.kobayashi@...aclelinux.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: netdev@...r.kernel.org, stable@...r.kernel.org,
linux-kernel@...r.kernel.org, hiraku.toyooka@...aclelinux.com,
Eric Dumazet <edumazet@...gle.com>, "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH 5.15 1/3] ipv6: annotate some data-races around
sk->sk_prot
On 2024/07/02 18:42, Greg KH wrote:
> On Mon, Apr 17, 2023 at 04:53:46PM +0000, Kazunori Kobayashi wrote:
>> From: Eric Dumazet <edumazet@...gle.com>
>>
>> commit 086d49058cd8471046ae9927524708820f5fd1c7 upstream.
>>
>> IPv6 has this hack changing sk->sk_prot when an IPv6 socket
>> is 'converted' to an IPv4 one with IPV6_ADDRFORM option.
>>
>> This operation is only performed for TCP and UDP, knowing
>> their 'struct proto' for the two network families are populated
>> in the same way, and can not disappear while a reader
>> might use and dereference sk->sk_prot.
>>
>> If we think about it all reads of sk->sk_prot while
>> either socket lock or RTNL is not acquired should be using READ_ONCE().
>>
>> Also note that other layers like MPTCP, XFRM, CHELSIO_TLS also
>> write over sk->sk_prot.
>>
>> BUG: KCSAN: data-race in inet6_recvmsg / ipv6_setsockopt
>>
>> write to 0xffff8881386f7aa8 of 8 bytes by task 26932 on cpu 0:
>> do_ipv6_setsockopt net/ipv6/ipv6_sockglue.c:492 [inline]
>> ipv6_setsockopt+0x3758/0x3910 net/ipv6/ipv6_sockglue.c:1019
>> udpv6_setsockopt+0x85/0x90 net/ipv6/udp.c:1649
>> sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3489
>> __sys_setsockopt+0x209/0x2a0 net/socket.c:2180
>> __do_sys_setsockopt net/socket.c:2191 [inline]
>> __se_sys_setsockopt net/socket.c:2188 [inline]
>> __x64_sys_setsockopt+0x62/0x70 net/socket.c:2188
>> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
>> entry_SYSCALL_64_after_hwframe+0x44/0xae
>>
>> read to 0xffff8881386f7aa8 of 8 bytes by task 26911 on cpu 1:
>> inet6_recvmsg+0x7a/0x210 net/ipv6/af_inet6.c:659
>> ____sys_recvmsg+0x16c/0x320
>> ___sys_recvmsg net/socket.c:2674 [inline]
>> do_recvmmsg+0x3f5/0xae0 net/socket.c:2768
>> __sys_recvmmsg net/socket.c:2847 [inline]
>> __do_sys_recvmmsg net/socket.c:2870 [inline]
>> __se_sys_recvmmsg net/socket.c:2863 [inline]
>> __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2863
>> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
>> entry_SYSCALL_64_after_hwframe+0x44/0xae
>>
>> value changed: 0xffffffff85e0e980 -> 0xffffffff85e01580
>>
>> Reported by Kernel Concurrency Sanitizer on:
>> CPU: 1 PID: 26911 Comm: syz-executor.3 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e-dirty #0
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>
>> Reported-by: syzbot <syzkaller@...glegroups.com>
>> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
>> Signed-off-by: David S. Miller <davem@...emloft.net>
>> Signed-off-by: Kazunori Kobayashi <kazunori.kobayashi@...aclelinux.com>
> This backport didn't apply at all, are you sure you made it against the
> proper tree?
>
> The original commit does seem to apply properly, so I'll go apply that
> one instead...
>
> greg k-h
I assumed the following commit is the latest version for 5.15 stable and
based the patch on this.
Is there any difference from your expectation?
commit 4878aadf2d1519f3731ae300ce1fef78fc63ee30 (tag: v5.15.161,
origin/linux-5.15.y, li
nux-5.15.y)
Author: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Date: Sun Jun 16 13:40:01 2024 +0200
Linux 5.15.161
Regards,
Kazunori
--
Kazunori Kobayashi
Cybertrust Japan Co., Ltd.
https://www.cybertrust.co.jp/
Powered by blists - more mailing lists