netdev - Re: [PATCH net-next 5/6] netlink: add mask validation

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:   Mon, 5 Oct 2020 15:21:10 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Michal Kubecek <mkubecek@...e.cz>, davem@...emloft.net,
        netdev@...r.kernel.org, kernel-team@...com, jiri@...nulli.us,
        andrew@...n.ch, dsahern@...il.com, pablo@...filter.org
Subject: Re: [PATCH net-next 5/6] netlink: add mask validation

On Mon, 05 Oct 2020 22:12:25 +0200 Johannes Berg wrote:
> On Mon, 2020-10-05 at 21:53 +0200, Johannes Berg wrote:
> > Hm. I like that idea.
> > 
> > If we have NLMSGERR_ATTR_OFFS we could accompany that with the sub-
> > policy for that particular attribute, something like
> > 
> > [NLMSGERR_ATTR_POLICY] = nested {
> >   [NL_POLICY_TYPE_ATTR_TYPE] = ...
> >   [NL_POLICY_TYPE_ATTR_MASK] = ...
> > }
> > 
> > which we could basically do by factoring out the inner portion of
> > netlink_policy_dump_write():
> > 
> > 	attr = nla_nest_start(skb, state->attr_idx);
> > 	if (!attr)
> > 		goto nla_put_failure;
> > 	...
> > 	nla_nest_end(skb, attr);
> > 
> > from there into a separate function, give it the pt and the nested
> > attribute (what's "state->attr_idx" here) as arguments, and then we call
> > it with NLMSGERR_ATTR_POLICY from here, and with "state->attr_idx" from
> > netlink_policy_dump_write() :-)
> > 
> > Nice, easy & useful, maybe I'll code it up tomorrow.  
> 
> OK I thought about it a bit more and looked at the code, and it's not
> actually possible to do easily right now, because we can't actually
> point to the bad attribute from the general lib/nlattr.c code ...
> 
> Why? Because we don't know right now, e.g. for nla_validate(), where in
> the message we started validation, i.e. the offset of the "head" inside
> the particular message.
> 
> For nlmsg_parse() and friends that's a bit easier, but it needs more
> rejiggering than I'm willing to do tonight ;)

I thought we'd record the const struct nla_policy *tp for the failing
attr in struct netlink_ext_ack and output based on that.