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
| ||
|
Message-ID: <04e00a96-5923-cd8f-78ab-752a6b34f8af@sangfor.com.cn> Date: Mon, 8 May 2023 14:28:55 +0800 From: Ding Hui <dinghui@...gfor.com.cn> To: Chuck Lever III <chuck.lever@...cle.com> Cc: "jlayton@...nel.org" <jlayton@...nel.org>, "trond.myklebust@...merspace.com" <trond.myklebust@...merspace.com>, "anna@...nel.org" <anna@...nel.org>, "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>, Bruce Fields <bfields@...hat.com>, Linux NFS Mailing List <linux-nfs@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH] SUNRPC: Fix UAF in svc_tcp_listen_data_ready() On 2023/5/8 12:00, Chuck Lever III wrote: > > >> On May 7, 2023, at 6:32 PM, Ding Hui <dinghui@...gfor.com.cn> wrote: >> >> On 2023/5/7 23:26, Chuck Lever III wrote: >>>> On May 7, 2023, at 5:11 AM, Ding Hui <dinghui@...gfor.com.cn> wrote: >>>> >>>> After the listener svc_sock freed, and before invoking svc_tcp_accept() >>>> for the established child sock, there is a window that the newsock >>>> retaining a freed listener svc_sock in sk_user_data which cloning from >>>> parent. In the race windows if data is received on the newsock, we will >>>> observe use-after-free report in svc_tcp_listen_data_ready(). >>> My thought is that not calling sk_odata() for the newsock >>> could potentially result in missing a data_ready event, >>> resulting in a hung client on that socket. >> >> I checked the vmcore, found that sk_odata points to sock_def_readable(), >> and the sk_wq of newsock is NULL, which be assigned by sk_clone_lock() >> unconditionally. >> >> Calling sk_odata() for the newsock maybe do not wake up any sleepers. >> >>> IMO the preferred approach is to ensure that svsk is always >>> safe to dereference in tcp_listen_data_ready. I haven't yet >>> thought carefully about how to do that. >> >> Agree, but I don't have a good way for now. > > Would a smartly-placed svc_xprt_get() hold the listener in place > until accept processing completes? > It is difficult and complicated to me. I think it's a little bit out of SUNRPC's control for the newsocks before accepted, e.g.: we don't know how many they have. Back to this RFC, I checked the code and thought it is safe by skipping sk_odata() for the newsocks before accepted in **svc_tcp_listen_data_ready()**, since these newsocks's sk_wq must be NULL, and will be assigned new one in sock_alloc_inode() called by kernel_accept(), so we can say if the child sock is not be accepted, there is nothing to be waked up. > >>>> Reproduce by two tasks: >>>> ... -- Thanks, - Ding Hui
Powered by blists - more mailing lists