netdev - Re: [PATCH net] net: hsr: remove seqnr

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: <20240905121701.mSxilT-9@linutronix.de>
Date: Thu, 5 Sep 2024 14:17:01 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, eric.dumazet@...il.com,
	syzbot <syzkaller@...glegroups.com>
Subject: Re: [PATCH net] net: hsr: remove seqnr_lock

On 2024-09-04 13:37:25 [+0000], Eric Dumazet wrote:
> syzbot found a new splat [1].
> 
> Instead of adding yet another spin_lock_bh(&hsr->seqnr_lock) /
> spin_unlock_bh(&hsr->seqnr_lock) pair, remove seqnr_lock
> and use atomic_t for hsr->sequence_nr and hsr->sup_sequence_nr.
> 
> This also avoid a race in hsr_fill_info().

You obtain to sequence nr without locking so two CPUs could submit skbs
at the same time. Wouldn't this allow the race I described in commit
   06afd2c31d338 ("hsr: Synchronize sending frames to have always incremented outgoing seq nr.")

to happen again? Then one skb would be dropped while sending because it
has lower sequence nr but in fact it was not yet sent.

Sebastian