netdev - Re: [PATCH RFC net] net: sockmap: avoid race between sock_map_destroy() and sk_psock

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZuTaGwM/8bTdWx1h@pop-os.localdomain>
Date: Fri, 13 Sep 2024 17:34:35 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Dmitry Antipov <dmantipov@...dex.ru>
Cc: John Fastabend <john.fastabend@...il.com>,
	Jakub Sitnicki <jakub@...udflare.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, lvc-project@...uxtesting.org
Subject: Re: [PATCH RFC net] net: sockmap: avoid race between
 sock_map_destroy() and sk_psock_put()

On Thu, Sep 12, 2024 at 06:59:39PM +0300, Dmitry Antipov wrote:
> On 9/11/24 7:45 PM, Cong Wang wrote:
> 
> > I guess you totally misunderstand my point. As a significant sockmap
> > contributor, I am certainly aware of sockmap users. My point is that I
> > needed to narrow down the problem to CONFIG_RDS when I was debugging it.
> 
> I've narrowed down the problem to possible race condition between two
> functions. "Narrowing down" the problem to a 17.5Kloc-sized subsystem
> is not too helpful.

Narrowing down from more 30 millions lines of code to 17.5K is already a huge
win to me, maybe not for you. :)

> 
> > So, please let me know if you can still reproduce this after disabling
> > CONFIG_RDS, because I could not reproduce it any more. If you can,
> > please kindly share the stack trace without rds_* functions.
> 
> Yes, this issue requires CONFIG_RDS and CONFIG_RDS_TCP to reproduce. But
> syzbot reproducer I'm working with doesn't create RDS sockets explicitly
> (with 'socket(AF_RDS, ..., ...)' or so). When two options above are enabled,
> the default network namespace has special kernel-space socket which is
> created in 'rds_tcp_listen_init()' and (if my understanding of the namespaces
> is correct) may be inherited with 'unshare(CLONE_NEWNET)'. So just enabling
> these two options makes the kernel vulnerable.

Thanks for confirming it.

I did notice the RDS kernel socket, but, without my patch, we can still
use sockops to hook TCP socket under the RDS socket and add it to a
sockmap, hence the conflict of sock->sk->sk_user_data.

My patch basically prevents such TCP socket under RDS socket from being
added to any sockmap.

> 
> So I'm still gently asking you to check whether there is a race condition
> I've talked about. Hopefully this shouldn't be too hard for a significant
> sockmap contributor.

If you can kindly explain why this race condition is not related to RDS
despite the fact it only happens with CONFIG_RDS enabled, I'd happy to
review it. Otherwise, I feel like you may head to a wrong direction.

Thanks.