linux-kernel - Re: [PATCHv5 net 1/3] bonding: fix calling sleeping function in spin lock and some race conditions

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] [day] [month] [year] [list]

Message-ID: <Z9Ddjgrxv5wQM-wV@fedora>
Date: Wed, 12 Mar 2025 01:04:14 +0000
From: Hangbin Liu <liuhangbin@...il.com>
To: Cosmin Ratiu <cratiu@...dia.com>
Cc: "kuba@...nel.org" <kuba@...nel.org>,
	"razor@...ckwall.org" <razor@...ckwall.org>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"jarod@...hat.com" <jarod@...hat.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	Tariq Toukan <tariqt@...dia.com>, Petr Machata <petrm@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"shuah@...nel.org" <shuah@...nel.org>,
	"steffen.klassert@...unet.com" <steffen.klassert@...unet.com>,
	"jv@...sburgh.net" <jv@...sburgh.net>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"horms@...nel.org" <horms@...nel.org>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
	Jianbo Liu <jianbol@...dia.com>
Subject: Re: [PATCHv5 net 1/3] bonding: fix calling sleeping function in spin
 lock and some race conditions

On Tue, Mar 11, 2025 at 09:08:49PM +0000, Cosmin Ratiu wrote:
> On Fri, 2025-03-07 at 09:03 -0800, Jakub Kicinski wrote:
> > On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote:
> > > TBH, keeping buggy code with a comment doesn't sound good to me.
> > > I'd rather remove this
> > > support than tell people "good luck, it might crash". It's better
> > > to be safe until a
> > > correct design is in place which takes care of these issues.
> > 
> > That's my feeling too, FWIW. I think we knew about this issue
> > for a while now, the longer we wait the more users we may disrupt
> > with the revert.
> 
> These are preexisting races between the bond link failover and the user
> removing the xfrm states. Unless the user wants to intentionally
> trigger these bugs, chances are nobody has ever encountered them in the
> wild in normal operation. In steady state, bond link failover works,
> and adding/removing states works. It's the combination of the two
> control plane events that may have a chance to double free or leak
> states.
> 
> I would not pull everything out just yet.
> 
> Today, I managed to find a solution for these races (I think), based on
> a patch series I am preparing against ipsec-next with other changes
> related to real_dev.
> 
> Hangbin, do you mind if I take over fixing the locking issue as part of
> my series? I plan to send it upstream the following days.

No, I don't mind. Please go ahead to fixing the locking issue. And thanks
a lot for your reviewing.

Regards
Hangbin