linux-kernel - Re: [PATCH net-next v24 09/23] ovpn: implement packet processing

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: <ae9f3c18-7b03-4a49-83a4-a3e7d8c52a3e@openvpn.net>
Date: Mon, 24 Mar 2025 21:53:02 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Donald Hunter <donald.hunter@...il.com>, Shuah Khan <shuah@...nel.org>,
 ryazanov.s.a@...il.com, Andrew Lunn <andrew+netdev@...n.ch>,
 Simon Horman <horms@...nel.org>, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, Xiao Liang <shaw.leon@...il.com>
Subject: Re: [PATCH net-next v24 09/23] ovpn: implement packet processing

On 24/03/2025 12:02, Sabrina Dubroca wrote:
> 2025-03-18, 02:40:44 +0100, Antonio Quartulli wrote:
>> +int ovpn_crypto_state_reset(struct ovpn_crypto_state *cs,
>> +			    const struct ovpn_peer_key_reset *pkr)
>> +{
>> +	struct ovpn_crypto_key_slot *old = NULL, *new;
>> +	u8 idx;
>> +
>> +	if (pkr->slot != OVPN_KEY_SLOT_PRIMARY &&
>> +	    pkr->slot != OVPN_KEY_SLOT_SECONDARY)
>> +		return -EINVAL;
>> +
>> +	new = ovpn_aead_crypto_key_slot_new(&pkr->key);
>> +	if (IS_ERR(new))
>> +		return PTR_ERR(new);
>> +
>> +	spin_lock_bh(&cs->lock);
> 
> At this point, should there be a check that we're not installing 2
> keys with the same key_id at the same time? I expect a well-behaved
> userspace never does that, but it would confuse
> ovpn_crypto_key_id_to_slot if it ever happened.
> 
> ["well, then the tunnel is broken. if userspace sets up a broken
> config that's not the kernel's problem." is an acceptable answer]
> 

The behaviour of ovpn_crypto_key_id_to_slot() is still "deterministic" 
as we will first lookup the primary key.

Therefore we will simply always use the primary key and never the other, 
which is what we should expect in this situation from the code.

I'd say this is just an ill-formed configuration, yet not invalid.
As per your statement, I'd say it's userspace's problem.

Cheers,


-- 
Antonio Quartulli
OpenVPN Inc.