netdev - Re: [PATCH net-next v6 17/25] ovpn: implement keepalive mechanism

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: <06406844-5d35-4e35-ae35-d34503d3549c@openvpn.net>
Date: Mon, 9 Sep 2024 11:17:18 +0200
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, kuba@...nel.org, pabeni@...hat.com,
 ryazanov.s.a@...il.com, edumazet@...gle.com, andrew@...n.ch
Subject: Re: [PATCH net-next v6 17/25] ovpn: implement keepalive mechanism

Hi,

On 03/09/2024 17:17, Sabrina Dubroca wrote:
> 2024-08-27, 14:07:57 +0200, Antonio Quartulli wrote:
>> +static time64_t ovpn_peer_keepalive_work_mp(struct ovpn_struct *ovpn,
>> +					    time64_t now)
>> +{
>> +	time64_t tmp_next_run, next_run = 0;
>> +	struct hlist_node *tmp;
>> +	struct ovpn_peer *peer;
>> +	int bkt;
>> +
>> +	spin_lock_bh(&ovpn->peers->lock_by_id);
>> +	hash_for_each_safe(ovpn->peers->by_id, bkt, tmp, peer, hash_entry_id) {
>> +		tmp_next_run = ovpn_peer_keepalive_work_single(peer, now);
>> +
>> +		/* the next worker run will be scheduled based on the shortest
>> +		 * required interval across all peers
>> +		 */
>> +		if (!next_run || tmp_next_run < next_run)
> 
> I think this should exclude tmp_next_run == 0.

or, for better clarity of the flow, I will add:

if (!tmp_next_run)
         continue;

since 0 explicitly means "keepalive disabled" or "no keepalive needed 
for $reasons".

> 
> If we have two peers, with the first getting a non-0 value and the 2nd
> getting 0, we'll end up with next_run = 0 on return.
> 
> If we have three peers and ovpn_peer_keepalive_work_single returns
> 12,0,42, we'll end up with 42 (after resetting to 0 on the 2nd peer),
> and we could miss sending the needed keepalive for peer 1.
> 

Absolutely. Thanks for pointing this out!

Cheers,

>> +			next_run = tmp_next_run;
>> +	}
>> +	spin_unlock_bh(&ovpn->peers->lock_by_id);
>> +
>> +	return next_run;
>> +}
> 

-- 
Antonio Quartulli
OpenVPN Inc.