linux-kernel - Re: [PATCH net-next 01/12] ipvlan: Support MACNAT mode

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: <25e65682-9df4-4257-94cd-be97f0a49867@huawei.com>
Date: Thu, 27 Nov 2025 11:13:11 +0300
From: Dmitry Skorodumov <skorodumov.dmitry@...wei.com>
To: Paolo Abeni <pabeni@...hat.com>, <netdev@...r.kernel.org>, Simon Horman
	<horms@...nel.org>, Kuniyuki Iwashima <kuniyu@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Xiao Liang <shaw.leon@...il.com>, Guillaume Nault
	<gnault@...hat.com>, Eric Dumazet <edumazet@...gle.com>, Julian Vetter
	<julian@...er-limits.org>, Stanislav Fomichev <sdf@...ichev.me>, Etienne
 Champetier <champetier.etienne@...il.com>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
CC: <andrey.bokhanko@...wei.com>, "David S. Miller" <davem@...emloft.net>,
	Jonathan Corbet <corbet@....net>, Andrew Lunn <andrew+netdev@...n.ch>
Subject: Re: [PATCH net-next 01/12] ipvlan: Support MACNAT mode


On 25.11.2025 15:58, Paolo Abeni wrote:
> On 11/20/25 6:49 PM, Dmitry Skorodumov wrote:
>> +static inline void ipvlan_mark_skb(struct sk_buff *skb, struct net_device *dev)
>> +{
>> +	IPVL_SKB_CB(skb)->mark = dev;
> +	if (ipvlan_is_skb_marked(skb, port->dev))
> ... and this is the receiver path. Nothing guaratees the CB is preserved
> in between and that random data in there will not confuse the above
> check. Also I'm not sure what you are trying to filter out here.

I need to recheck.. unfortunately I didn't wrote enough comments here and now unsure about some details..

>> @@ -597,6 +690,9 @@ int ipvlan_link_new(struct net_device *dev, struct rtnl_newlink_params *params,
>>  	port = ipvlan_port_get_rtnl(phy_dev);
>>  	ipvlan->port = port;
>>  
>> +	if (data && data[IFLA_IPVLAN_FLAGS])
>> +		port->flags = nla_get_u16(data[IFLA_IPVLAN_FLAGS]);
> This looks like a change of behavior that could potentially break the
> user-space.
>
>> +
>>  	/* If the port-id base is at the MAX value, then wrap it around and
>>  	 * begin from 0x1 again. This may be due to a busy system where lots
>>  	 * of slaves are getting created and deleted.
>> @@ -625,19 +721,13 @@ int ipvlan_link_new(struct net_device *dev, struct rtnl_newlink_params *params,
>>  	if (err)
>>  		goto remove_ida;
>>  
>> -	/* Flags are per port and latest update overrides. User has
>> -	 * to be consistent in setting it just like the mode attribute.
>> -	 */
>> -	if (data && data[IFLA_IPVLAN_FLAGS])
>> -		port->flags = nla_get_u16(data[IFLA_IPVLAN_FLAGS]);
>> -
>> -	if (data && data[IFLA_IPVLAN_MODE])
>> -		mode = nla_get_u16(data[IFLA_IPVLAN_MODE]);
>> -
>>  	err = ipvlan_set_port_mode(port, mode, extack);
>>  	if (err)
>>  		goto unlink_netdev;
>>  
>>
Hm... What am I missing? The intention was to know "mode" a bit earlier and generate MAC as random for macnat-mode.. it's supposed to be just a simple line move a bit upper in the code

PS: I agree with other issues and will work on it

Dmitry