netdev - Re: [PATCH net-next 05/13] genetlink: check for callback type at op load time

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]

Date:   Wed, 19 Oct 2022 14:33:39 -0700
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>, <davem@...emloft.net>,
        <johannes@...solutions.net>
CC:     <netdev@...r.kernel.org>, <edumazet@...gle.com>,
        <pabeni@...hat.com>, <jiri@...nulli.us>, <razor@...ckwall.org>,
        <nicolas.dichtel@...nd.com>, <gnault@...hat.com>, <fw@...len.de>
Subject: Re: [PATCH net-next 05/13] genetlink: check for callback type at op
 load time



On 10/18/2022 4:07 PM, Jakub Kicinski wrote:
> Now that genl_get_cmd_split() is informed what type of callback
> user is trying to access (do or dump) we can check that this
> callback is indeed available and return an error early.
> 
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
> ---
>  net/netlink/genetlink.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 26ddbd23549d..9dfb3cf89b97 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -166,11 +166,17 @@ static int genl_get_cmd(u32 cmd, const struct genl_family *family,
>  	return genl_get_cmd_small(cmd, family, op);
>  }
>  
> -static void
> +static int
>  genl_cmd_full_to_split(struct genl_split_ops *op,
>  		       const struct genl_family *family,
>  		       const struct genl_ops *full, u8 flags)
>  {
> +	if ((flags & GENL_CMD_CAP_DO && !full->doit) ||
> +	    (flags & GENL_CMD_CAP_DUMP && !full->dumpit)) {
> +		memset(op, 0, sizeof(*op));
> +		return -ENOENT;
> +	}
> +

Should this check that exactly one of GENL_CMD_CAP_DO and
GENL_CMD_CAP_DUMP is set? Or is some earlier flow enforcing this?

Thanks,
Jake