From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793831777; b=cx1qrDWsl7rIIeM9GmIHljd842NcRcm77xrW1biIBySSHI2CqSymplpt5FuY5Rg/oYG/ gaBHtRQc3208MiR94Vbf7dskrPL1ChDAE1rq28SiwKlzOuuaX5rHBih41K72/BfHAKxrs cu9h+MTdVUwYzd5qgsprGxuGhwCUyGN9Ogyf5v4riIL0kqq4x3DDMfE0wV7J7WPTx/uHI g2h8ST8kIQA/CvkBdTeABGGx1XdV3zwUxBBHe6TmV37kWx6cVo8SV0/brwiiAnu8o6N07 dOqElPlgTwIyID1l6LcGcG9E97gJb+wYTG9XtmfO7WDab6K0nLWhhdcAw1lGiO+NZhg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793831777; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=4gYi25wjANmifuLQ6UQcnsEMdKnrXe9DVgVwLrOD5vw=; b=3aCLvfqlUZ7WMmUP6/lC2YEGpwGMDkm6k1ug9Mjtp3of1ruApA8HsnObsnqUJTfLZayR DJjEPe4helTDxCD+bLbxIsVAMFOy8FrSdoyr7Y3CjlKchbNpSfhuTXr03Vuwy9q4RV93Y YvsaAlcYi0T3OdnbuIFhM9UXI/ERRQDXFiV6jGgBN8iJ3gi4VDYFIsgu8QByNzRDbM1wo Av+fWGS8ljgzdO66IH8u3wcVFGUF+xjtJ9vEe+HsR20p1Zg/MRmIvWqAYmw+Pw+jtid3S mJxOpdCfn4Hsr9HTU0A6cRIAuk9p7hmn0bwt7mHdmqosKcIu+/9N6jcUxmTzoepzReQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=D7muX9jx; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9197606A326; Wed, 4 Nov 2026 22:36:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=D7muX9jx Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4789A1F000C1; Wed, 4 Nov 2026 22:36:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793831776; bh=4gYi25wjANmifuLQ6UQcnsEMdKnrXe9DVgVwLrOD5vw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=D7muX9jxW/V1oEfS2HzorClv3PwPn/USKtouktMYmvsZt8oXin16CpKB8kabjMvhn aUeZWBujTGyzxzMVAKV3JxuxDyNNbnkirXtm9kaDtAlk7A2LiywuMzhuaK2xrwGwXd pKKFeQdHVohkNch3V84lLOdM00iq1V1BiW7vtF/k= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Jeff Layton , Chuck Lever Subject: [PATCH 6.18 0905/1005] NFSD: validate transport name in listener_set before serv creation Date: Wed, 4 Nov 2026 16:10:38 -0500 Message-ID: <20261104211108.534659903@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261104211043.516122098@linuxfoundation.org> References: <20261104211043.516122098@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jeff Layton commit 421becdc5cf4d7d2fbda393e78ca76d25d277c0f upstream. nfsd_nl_listener_set_doit() holds nfsd_mutex for the whole listener teardown and rebuild. The code checks NFSD_A_SOCK_TRANSPORT_NAME for presence only, and not for content. An arbitrary name therefore reaches svc_xprt_create_from_sa(). There, a name that matches no registered class calls request_module("svc%s", name). That call is a TASK_KILLABLE usermode helper upcall, and it runs under nfsd_mutex. Check the name against the classes that NFSD can create: tcp, udp and rdma. The check goes in nfsd_nl_validate_listeners(), which runs before the code takes nfsd_mutex. The rejection names the offending attribute through extack, since -EPROTONOSUPPORT on its own does not say which entry carried the bad name. This narrows the upcall. It does not remove it. NFSD accepts "rdma" without a condition, so on a kernel that does not build svcrdma the name still reaches request_module("svcrdma") under nfsd_mutex. That is necessary for the modular case, where the autoload is legitimate. Fixes: 16a471177496 ("NFSD: add listener-{set,get} netlink command") Cc: stable@vger.kernel.org Assisted-by: LLM Link: https://syzkaller.appspot.com/bug?extid=c7eae0eb80858a2dba0f Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260901-nfsd-nl-hang-v5-2-a540d86668b0@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman --- fs/nfsd/nfsctl.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) --- a/fs/nfsd/nfsctl.c +++ b/fs/nfsd/nfsctl.c @@ -1932,6 +1932,23 @@ err_free_msg: return err; } +/* + * Transport classes NFSD knows how to instantiate. Vetting the name here + * keeps a bogus string from reaching svc_xprt_create_from_sa(), where an + * unknown name triggers a request_module("svc%s", name) upcall under + * nfsd_mutex. + */ +static bool nfsd_nl_transport_supported(const char *name) +{ + static const char * const supported[] = { "tcp", "udp", "rdma" }; + int i; + + for (i = 0; i < ARRAY_SIZE(supported); i++) + if (!strcmp(name, supported[i])) + return true; + return false; +} + /* Upper bound on the number of listeners a single request may carry. */ #define NFSD_NL_LISTENER_MAX 1024 @@ -1969,6 +1986,13 @@ static int nfsd_nl_validate_listeners(st if (!tb[NFSD_A_SOCK_ADDR] || !tb[NFSD_A_SOCK_TRANSPORT_NAME]) return -EINVAL; + if (!nfsd_nl_transport_supported(nla_data(tb[NFSD_A_SOCK_TRANSPORT_NAME]))) { + NL_SET_ERR_MSG_ATTR(info->extack, + tb[NFSD_A_SOCK_TRANSPORT_NAME], + "unsupported transport name"); + return -EPROTONOSUPPORT; + } + sa = nla_data(tb[NFSD_A_SOCK_ADDR]); if (nla_len(tb[NFSD_A_SOCK_ADDR]) < sizeof(sa->sa_family)) return -EINVAL;