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: <Z86aj4Ak0ksyTrmo@fedora>
Date: Mon, 10 Mar 2025 07:53:51 +0000
From: Hangbin Liu <liuhangbin@...il.com>
To: Jay Vosburgh <jv@...sburgh.net>,
	Steffen Klassert <steffen.klassert@...unet.com>,
	Jakub Kicinski <kuba@...nel.org>
Cc: Nikolay Aleksandrov <razor@...ckwall.org>, netdev@...r.kernel.org,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, Shuah Khan <shuah@...nel.org>,
	Tariq Toukan <tariqt@...dia.com>, Jianbo Liu <jianbol@...dia.com>,
	Jarod Wilson <jarod@...hat.com>, Cosmin Ratiu <cratiu@...dia.com>,
	Petr Machata <petrm@...dia.com>, linux-kselftest@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHv5 net 1/3] bonding: fix calling sleeping function in spin
 lock and some race conditions

On Fri, Mar 07, 2025 at 09:03:32AM -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.

Steffen said we can't sleep in xfrm_timer_handler(), which calls
__xfrm_state_delete(). So I can't find a way to handle the race condition
between bond_ipsec_add_sa_all() -> xdo_dev_state_add, which may sleep.
And __xfrm_state_delete() -> xdo_dev_state_delete, which can't sleep.

Hi Jay, do you have any comments?

Thanks
Hangbin