Message ID | 7186dae6d951495f6918c45f8250e6407d71e88f.1670878949.git.christophe.jaillet@wanadoo.fr |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2465591wrr; Mon, 12 Dec 2022 13:06:48 -0800 (PST) X-Google-Smtp-Source: AA0mqf73xDGlD+Z9NqAMUqwXbbG5mDm0MlSI89XqF95ZoR9wUAOlU/3sMZtcQvEhDyUdbUI8t5GI X-Received: by 2002:a17:906:405:b0:7c0:affa:866f with SMTP id d5-20020a170906040500b007c0affa866fmr14414165eja.26.1670879208130; Mon, 12 Dec 2022 13:06:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670879208; cv=none; d=google.com; s=arc-20160816; b=g7B59b7SE6rI26+dp3p469GNZFxF964mDLLt41Sf18EFrsxqFi5S2HkEXBYI+KccIa F8tE7mD/yYRaP3UXN4NwhcqUK1otqieBe2yX/usa2lf19q0owrFzDfqj8PIxrj/D9/ms +I0sneQJTdQ9NP+LCSodo1oW3afbTO9QEz4iqHLdLN2pSaPajHQlgYX01D4/s4Q6qixc dSBga2K/OoLXK3vsJMFV5yh2IMtXCIqzyp/pBsV5actdKki0oFfgIhRAmTLWMj4KlefU KZNCd4oGmL++CZqKPXCbylmVS12owaAqDd1ojL2++tndcdGQ8+K7/i2MAtR3DkmY6ZDt loOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=4x+w5uqY6SNtLvnFDiNrZm7FcWjNR3yj1jwDNThfcIE=; b=YDxCDgvlNXXRFrOrIdJx4NMW7yyZmco0uVAAI3CxSxD0NI+WWpXdT2QndQ8/s0qIIl E+g3hiOyeVgen3/DuBMNPOkuvP3fMa3pIaLQ9DaKhDsPHAhnZ94vy4ObigjoAVTSSdb+ ETsntRlgTadbOVzBF5Hg9iWVjsvzqhcx8p/fn8mJoE2k4NewxXuPNnIkkp5cO576D5gC oAoWeEHg2s05eW8yAfQt5OtSCxXJ16Bns5UMWZBW1UX5MBb/WeGKGCc/IC69do8yBqih SBUL9cDyhYfDhHM2NdIdqOjncplTxuKnKMbzOMMjukMRyt3v0G6u0D4sfRobeYCtNX3J lDow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dr21-20020a170907721500b0079800b8172bsi7280028ejc.450.2022.12.12.13.06.21; Mon, 12 Dec 2022 13:06:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233142AbiLLVFC (ORCPT <rfc822;jeantsuru.cumc.mandola@gmail.com> + 99 others); Mon, 12 Dec 2022 16:05:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233479AbiLLVEk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 12 Dec 2022 16:04:40 -0500 Received: from smtp.smtpout.orange.fr (smtp-23.smtpout.orange.fr [80.12.242.23]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 860DB192AC for <linux-kernel@vger.kernel.org>; Mon, 12 Dec 2022 13:03:13 -0800 (PST) Received: from pop-os.home ([86.243.100.34]) by smtp.orange.fr with ESMTPA id 4px6pWxRHfRXa4px6p0kgM; Mon, 12 Dec 2022 22:03:10 +0100 X-ME-Helo: pop-os.home X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Mon, 12 Dec 2022 22:03:10 +0100 X-ME-IP: 86.243.100.34 From: Christophe JAILLET <christophe.jaillet@wanadoo.fr> To: "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Jacob Keller <jacob.e.keller@intel.com> Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Christophe JAILLET <christophe.jaillet@wanadoo.fr>, netdev@vger.kernel.org Subject: [PATCH net] genetlink: Fix an error handling path in ctrl_dumppolicy_start() Date: Mon, 12 Dec 2022 22:03:06 +0100 Message-Id: <7186dae6d951495f6918c45f8250e6407d71e88f.1670878949.git.christophe.jaillet@wanadoo.fr> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752043836767865041?= X-GMAIL-MSGID: =?utf-8?q?1752043836767865041?= |
Series |
[net] genetlink: Fix an error handling path in ctrl_dumppolicy_start()
|
|
Commit Message
Christophe JAILLET
Dec. 12, 2022, 9:03 p.m. UTC
If this memory allocation fails, some resources need to be freed.
Add the missing goto to the error handling path.
Fixes: b502b3185cd6 ("genetlink: use iterator in the op to policy map dumping")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This patch is speculative.
This function is a callback and I don't know how the core works and handles
such situation, so review with care!
More-over, should this kmalloc() be a kzalloc()?
genl_op_iter_init() below does not initialize all fields, be they are maybe
set correctly before uses.
---
net/netlink/genetlink.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Comments
On Mon, 12 Dec 2022 22:03:06 +0100 Christophe JAILLET wrote: > If this memory allocation fails, some resources need to be freed. > Add the missing goto to the error handling path. > > Fixes: b502b3185cd6 ("genetlink: use iterator in the op to policy map dumping") > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > --- > This patch is speculative. > > This function is a callback and I don't know how the core works and handles > such situation, so review with care! It's fine, the function has pretty much two completely separate paths. Dump all ops and dump a single op. Anything that allocs state before this point is on the single op path, while the iterator is only allocated for dump all. This should be evident from the return 0; at the end of the if (tb[CTRL_ATTR_OP]) > More-over, should this kmalloc() be a kzalloc()? > genl_op_iter_init() below does not initialize all fields, be they are maybe > set correctly before uses. It's fine, op_iters are put on the stack without initializing, iter init must (and currently does) work without depending on zeroed memory.
> -----Original Message----- > From: Jakub Kicinski <kuba@kernel.org> > Sent: Monday, December 12, 2022 1:10 PM > To: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > Cc: David S. Miller <davem@davemloft.net>; Eric Dumazet > <edumazet@google.com>; Paolo Abeni <pabeni@redhat.com>; Keller, Jacob E > <jacob.e.keller@intel.com>; linux-kernel@vger.kernel.org; kernel- > janitors@vger.kernel.org; netdev@vger.kernel.org > Subject: Re: [PATCH net] genetlink: Fix an error handling path in > ctrl_dumppolicy_start() > > On Mon, 12 Dec 2022 22:03:06 +0100 Christophe JAILLET wrote: > > If this memory allocation fails, some resources need to be freed. > > Add the missing goto to the error handling path. > > > > Fixes: b502b3185cd6 ("genetlink: use iterator in the op to policy map dumping") > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > --- > > This patch is speculative. > > > > This function is a callback and I don't know how the core works and handles > > such situation, so review with care! > > It's fine, the function has pretty much two completely separate paths. > Dump all ops and dump a single op. > Anything that allocs state before this point is on the single op path, > while the iterator is only allocated for dump all. > This should be evident from the return 0; at the end of the > if (tb[CTRL_ATTR_OP]) > > > More-over, should this kmalloc() be a kzalloc()? > > genl_op_iter_init() below does not initialize all fields, be they are maybe > > set correctly before uses. I personally prefer using kzalloc even if we know its not necessary, except in cases where performance of the allocation matters. It helps reduce the burden of review as one doesn't need to think "was this initialized?" at least for the problem of leaking kernel internals. I know there are also some tools like UBSAN and others which might be able to detect access to uninitialized memory, but I am not sure if they're capable enough at present to handle memory returned by kmalloc or not. If they are, then there could be advantage in detecting cases where you did fully expect initialization to be done. > > It's fine, op_iters are put on the stack without initializing, iter > init must (and currently does) work without depending on zeroed memory. The above said, I think the analysis here is correct and that kmalloc is ok here. Thanks, Jake
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c index 600993c80050..7b9f04bd85a2 100644 --- a/net/netlink/genetlink.c +++ b/net/netlink/genetlink.c @@ -1451,8 +1451,10 @@ static int ctrl_dumppolicy_start(struct netlink_callback *cb) } ctx->op_iter = kmalloc(sizeof(*ctx->op_iter), GFP_KERNEL); - if (!ctx->op_iter) - return -ENOMEM; + if (!ctx->op_iter) { + err = -ENOMEM; + goto err_free_state; + } genl_op_iter_init(rt, ctx->op_iter); ctx->dump_map = genl_op_iter_next(ctx->op_iter);