From: Simon Horman <horms@kernel.org>
To: kovalev@altlinux.org
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, jiri@resnulli.us,
jacob.e.keller@intel.com, johannes@sipsolutions.net,
idosch@nvidia.com, David Lebrun <david.lebrun@uclouvain.be>
Subject: Re: [PATCH] genetlink: fix potencial use-after-free and null-ptr-deref in genl_dumpit()
Date: Mon, 19 Feb 2024 11:32:40 +0000 [thread overview]
Message-ID: <20240219113240.GZ40273@kernel.org> (raw)
In-Reply-To: <20240215202309.29723-1-kovalev@altlinux.org>
+ Jiri Pirko <jiri@resnulli.us>
David Lebrun <david.lebrun@uclouvain.be>
On Thu, Feb 15, 2024 at 11:23:09PM +0300, kovalev@altlinux.org wrote:
> From: Vasiliy Kovalev <kovalev@altlinux.org>
>
> The pernet operations structure for the subsystem must be registered
> before registering the generic netlink family.
>
> Fixes: 134e63756d5f ("genetlink: make netns aware")
Hi Vasiliy,
A Fixes tag implies that this is a bug fix.
So I think some explanation is warranted of what, user-visible,
problem this resolves.
In that case the patch should be targeted at net.
Which means it should be based on that tree and have a net annotation
in the subject
Subject: [PATCH net] ...
Alternatively, the Fixes tag should be dropped and some explanation
should be provided of why the structure needs to be registered before
the family.
In this case, if you wish to refer to the patch where the problem (but not
bug) was introduced you can use something like the following.
It is just the Fixes tag that has a special meaning.
Introduced in 134e63756d5f ("genetlink: make netns aware")
I think the above comments also apply to:
- [PATCH] ipv6: sr: fix possible use-after-free and null-ptr-deref
https://lore.kernel.org/all/20240215202717.29815-1-kovalev@altlinux.org/
- [PATCH] devlink: fix possible use-after-free and memory leaks in devlink_init()
https://lore.kernel.org/all/20240215203400.29976-1-kovalev@altlinux.org/
And as these patches seem to try to fix the same problem in different
places, all under Networking, I would suggest that if you do repost,
they are combined into a patch series (3 patches in the same series).
But I do wonder, how such an apparently fundamental problem has been
present for so long in what I assume to be well exercised code.
Also, potential is misspelt in the subject of this patch.
> Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
> ---
> net/netlink/genetlink.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 8c7af02f845400..3bd628675a569f 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -1879,14 +1879,16 @@ static int __init genl_init(void)
> {
> int err;
>
> - err = genl_register_family(&genl_ctrl);
> - if (err < 0)
> - goto problem;
> -
> err = register_pernet_subsys(&genl_pernet_ops);
> if (err)
> goto problem;
>
> + err = genl_register_family(&genl_ctrl);
> + if (err < 0) {
> + unregister_pernet_subsys(&genl_pernet_ops);
> + goto problem;
The problem label calls panic().
As noted elsewhere [1] there is no expectation of recovering from panic(),
so there is no need to clean up here.
[1] https://lore.kernel.org/all/CANn89i+TNVtk8UT1+2QeeKHR-b6AQoopdxpcqcbNVOp9+JYSYw@mail.gmail.com/
> + }
> +
> return 0;
>
> problem:
> --
> 2.33.8
>
>
--
pw-bot: changes-requested
next prev parent reply other threads:[~2024-02-19 11:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 20:23 [PATCH] genetlink: fix potencial use-after-free and null-ptr-deref in genl_dumpit() kovalev
2024-02-19 11:32 ` Simon Horman [this message]
2024-02-19 12:15 ` kovalev
2024-02-20 13:02 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240219113240.GZ40273@kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=david.lebrun@uclouvain.be \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=jacob.e.keller@intel.com \
--cc=jiri@resnulli.us \
--cc=johannes@sipsolutions.net \
--cc=kovalev@altlinux.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).