netdev - Re: [PATCH net-next 09/20] rtnetlink: Update rtnl_bridge

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: <7a8895a8-47b0-cfc5-7f8f-bc4f3143fd60@gmail.com>
Date:   Sun, 7 Oct 2018 19:31:16 -0600
From:   David Ahern <dsahern@...il.com>
To:     Christian Brauner <christian@...uner.io>,
        David Ahern <dsahern@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, jbenc@...hat.com,
        stephen@...workplumber.org
Subject: Re: [PATCH net-next 09/20] rtnetlink: Update rtnl_bridge_getlink for
 strict data checking

On 10/7/18 4:36 AM, Christian Brauner wrote:
>> +	if (cb->strict_check) {
>> +		struct ifinfomsg *ifm;
>>  
>> -		extfilt = nlmsg_find_attr(cb->nlh, sizeof(struct ifinfomsg),
>> -					  IFLA_EXT_MASK);
>> -		if (extfilt) {
>> -			if (nla_len(extfilt) < sizeof(filter_mask))
>> -				return -EINVAL;
>> +		if (nlh->nlmsg_len < nlmsg_msg_size(sizeof(*ifm))) {
>> +			NL_SET_ERR_MSG(extack, "Invalid header");
>> +			return -EINVAL;
>> +		}
>> +
>> +		ifm = nlmsg_data(nlh);
>> +		if (ifm->__ifi_pad || ifm->ifi_type || ifm->ifi_flags ||
>> +		    ifm->ifi_change || ifm->ifi_index) {
>> +			NL_SET_ERR_MSG(extack, "Invalid values in header for dump request");
>> +			return -EINVAL;
>> +		}
>> +	}
>>  
>> -			filter_mask = nla_get_u32(extfilt);
>> +	err = nlmsg_parse(nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
>> +			  ifla_policy, extack);
>> +	if (err < 0) {
>> +		if (cb->strict_check)
>> +			return -EINVAL;
>> +		goto walk_entries;
>> +	}
> 
> What's the point of moving this out of the
> if (cb->strict_check) {} branch above? This looks like it would cause
> the same parse warnings that we're trying to get rid of in inet{4,6}
> dumps.

Link messages don't have the problem in general because they use
ifinfomsg as the header - which is the one abused for other message
types. That said ...

> Seems to make more sense to make the nlmsg_parse() itself conditional as
> well unless I'm lacking context.

... I now have nlmsg_parse and nlmsg_parse_strict.