From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f4.google.com (mail-wm2-f4.google.com [74.125.225.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A04223B1034 for ; Sun, 19 Jul 2026 18:09:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784484588; cv=none; b=dlWaI0emv+/wGBX0U/Lys0otlT9RMp1H0tU4Q8i0T/Obj7lKurGKm1v4OZZBE/5nAwUJBJk1M9qEK4yzZPbhnxq4bCxQapslPDM7BIITrtZO8AmMbVlx+S7+nPFxFiRxYBHSBrvOHYK3wU0pSdaUN6PPikR583OiH4vP+391srI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784484588; c=relaxed/simple; bh=RcuCVJLUxcCDd1eWJ/F0/033hxnFIW+7FtOC8MWJx2c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PnsJJmUcrYVK/e9nimMbhHfY0qeVVeydqTyfUHzvxkyD5LkCWkt5sB9kPzyPIMpcFhaJ0ZUsz3FzQIiJg97/j/IRDUw7Quifi/qIvJZDxYpT+R26hINb6G8cTOUkYJ7iw7r/rY1BFPdzEgWf9BaqglhYP7a6N3ESYtMJMZ7JANk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JQ7ySA0B; arc=none smtp.client-ip=74.125.225.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JQ7ySA0B" Received: by mail-wm2-f4.google.com with SMTP id 5b1f17b1804b1-4955f00e593so114225e9.0 for ; Sun, 19 Jul 2026 11:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784484581; x=1785089381; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=RcuCVJLUxcCDd1eWJ/F0/033hxnFIW+7FtOC8MWJx2c=; b=JQ7ySA0Bvkd1lzXjNs2QQKPBkXN0jbOfH7A4QBF5oHqh+4L8+WTOzxZa2FgAyjwqJu CQSpGUK+gKs3w6KS46uAwjsEDxeAsJwEvsD1QqITXdwAyiz71+HX70Uto2JvGA0efMpk M4BO2kCbBkR0etoI71Ivzmk9Du+nfyaIwYxBvHRYpHUJXUeq19Lc5z/SdIToCzVVHuOG RGw92jAkdY5onh6wvJL/JyH/pHtOrmTs8pYlPZjIfSrE9RqcoMBe9baLO5LzdHRoGRT6 qC0RcDeNY5H95vFDAdS7xfiAs6NDNGTVWgqVxI8IXOLSHic1u98jzVchO1IYQoLM+QMM 9s9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784484581; x=1785089381; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=RcuCVJLUxcCDd1eWJ/F0/033hxnFIW+7FtOC8MWJx2c=; b=a8Tx80HebeQvX8UzfUdUbMhgzJXXePgGEiaSsolBmgMu8MHUrTEFttY/1orPnYx84K RuJ1lJTq6JvdNnZoqIkIUH0TK1bP+g19/Pfw7QNuvnfAX1Jgt4N5xLOWZRBlbiqdD2wO 2IsmRqjYaDQKd5ZGRZzKy/ouABytdzR50u3KdSzbJBZjjdJo98TdyjV8CXX1/DXtDutG DiX/mdUS0HSs2Fa1McD3jgucLGUz2WQWNjvElOYyJ80WxLHnsg3dzBTzuwm7eRU1PE8m KVWubD41cuanbyqSod6iiZrLuYgq12GrrKLSbCRXIni4+yJ4vWS2n04Uab9rQvfBDfEC xZtg== X-Forwarded-Encrypted: i=1; AHgh+Rqgv60tVtNvgJWDJ+sgUfeEAYo1DJ/B8GHjWn9HMxqylBYDdrIV8IUXdgY9M73Dh6vxMGqAlGwd+SdGTGM=@vger.kernel.org X-Gm-Message-State: AOJu0YzF7kMhYRvWUlZ1IlDcgBXJeCW7Nscu/5g9YKvOfHU2hOUsbynK TohKVtMWfOKJ0fwlmJVOAdRTQmqTygCoYwtFujFE0X59T4U6QM1hEX+O X-Gm-Gg: AfdE7clogrlJyTqn51zDI8pW3Cav2Z1M0pJwneS185xXZscUpXSLq0XltqbqH2lHsJ0 PclS7ot9OxS0oDgHei5uSTSgb7DF3eBgCQHx0dZNHHM+X/zI7swgbmEkwZW3fA1QRlatZLYGmTy zyemngjgF9YsracxLgUQZN2MdS7G7F2lYMm9Zn9RVhRqbaBg55VWJKDxKMJDnz8gdNn5R42p41S ceftN9mmEHr3Pe/UCnFiath7t0gPUXaGwa+HDJITDaa1bE9P6vf7u2D1GL95LFpjoyPLyAFhTPG VsK9uLrDFrbJr6TezbknBmvaIxAOSdwbAjMYcySoSD3BKuX/5vLwzC8PCbfjqx/zV1h3Ap9jPW+ Ao5sjevwZ19yBAwthmmmplOpyCCTKoeKcXy/BC+1Rk4l7y5PW996TPm8Xh/W5BwVPH3Yl90hQ79 MT X-Received: by 2002:a05:600c:b85:b0:495:5365:c0d1 with SMTP id 5b1f17b1804b1-49553d85ea0mr67524515e9.14.1784484581394; Sun, 19 Jul 2026 11:09:41 -0700 (PDT) Received: from fedora ([212.253.209.56]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f63edda29sm23296214f8f.32.2026.07.19.11.09.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jul 2026 11:09:40 -0700 (PDT) From: Serhat Kumral To: Jason Gunthorpe Cc: Leon Romanovsky , Zhu Yanjun , Zhu Yanjun , David Ahern , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+8c9eede336e3a843750e@syzkaller.appspotmail.com Subject: Re: [RFC PATCH 1/2] RDMA/rxe: drive UDP tunnel socket lifetime from the GID table Date: Sun, 19 Jul 2026 20:54:47 +0300 Message-ID: <20260719175447.196499-1-serhatkumral1@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260718153927.GF701389@ziepe.ca> References: <20260718153927.GF701389@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit > Don't get this, GID removal is asynchronous, so it will eventually > complete, what is wrong with leaving the socks around but unsuable for > a little bit? Does something break? I checked this more closely. You are right that a kernel socket's passive net reference keeps struct net itself allocated, so my wording about closing the sockets before the net is freed was inaccurate. However, the passive reference does not defer the pernet exit callbacks. cleanup_net runs those callbacks before dropping its base passive reference. With CONFIG_PROC_FS, sock_inuse_exit_net() frees net->core.prot_inuse; when per-netns UDP hash tables are enabled, udp_pernet_table_free() also frees net->ipv4.udp_table. The eventual udp_tunnel_sock_release() reaches udp_lib_unhash(), which accesses this state while unhashing a still-hashed socket. A sufficiently delayed close can therefore access freed pernet storage even though struct net itself remains allocated. The backstop is therefore intended to close any remaining hashed sockets while the required protocol pernet state is still alive, not to prevent a direct struct net UAF. I will reword the comment and commit message accordingly in the next version. Regarding the per-QP TX socket in init_net, agreed that it should be investigated separately. I will keep that out of this series and look at selecting the TX socket from the relevant GID/netns as a follow-up.