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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+eW0E9HMPxndN2p@corigine.com>
Date:   Sat, 11 Feb 2023 14:23:28 +0100
From:   Simon Horman <simon.horman@...igine.com>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
        davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
        edumazet@...gle.com, moshe@...dia.com
Subject: Re: [patch net-next] devlink: don't allow to change net namespace
 for FW_ACTIVATE reload action

On Fri, Feb 10, 2023 at 11:43:04AM -0800, Jacob Keller wrote:
> 
> 
> On 2/10/2023 5:15 AM, Simon Horman wrote:
> > On Fri, Feb 10, 2023 at 12:58:27PM +0100, Jiri Pirko wrote:
> >> From: Jiri Pirko <jiri@...dia.com>
> >>
> >> The change on network namespace only makes sense during re-init reload
> >> action. For FW activation it is not applicable. So check if user passed
> >> an ATTR indicating network namespace change request and forbid it.
> >>
> >> Fixes: ccdf07219da6 ("devlink: Add reload action option to devlink reload command")
> >> Signed-off-by: Jiri Pirko <jiri@...dia.com>
> >> ---
> >> Sending to net-next as this is not actually fixing any real bug,
> >> it just adds a forgotten check.
> >> ---
> >>  net/devlink/dev.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/net/devlink/dev.c b/net/devlink/dev.c
> >> index 78d824eda5ec..a6a2bcded723 100644
> >> --- a/net/devlink/dev.c
> >> +++ b/net/devlink/dev.c
> >> @@ -474,6 +474,11 @@ int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
> >>  	if (info->attrs[DEVLINK_ATTR_NETNS_PID] ||
> >>  	    info->attrs[DEVLINK_ATTR_NETNS_FD] ||
> >>  	    info->attrs[DEVLINK_ATTR_NETNS_ID]) {
> >> +		if (action != DEVLINK_RELOAD_ACTION_DRIVER_REINIT) {
> >> +			NL_SET_ERR_MSG_MOD(info->extack,
> >> +					   "Changing namespace is only supported for reinit action");
> >> +			return -EOPNOTSUPP;
> >> +		}
> > 
> > Is this also applicable in the case where the requested ns (dest_net)
> > is the same as the current ns, which I think means that the ns
> > is not changed?
> > 
> 
> In that case wouldn't userspace simply not add the attribute though?

Yes, that may be the case.
But my question is about the correct behaviour if user space doesn't do that.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ