netdev - Re: [PATCH AUTOSEL 6.15 044/118] openvswitch: Stricter validation for the userspace action

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: <2025060520-slacking-swimmer-1b31@gregkh>
Date: Thu, 5 Jun 2025 16:45:39 +0200
From: Greg KH <greg@...ah.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Ilya Maximets <i.maximets@....org>, Sasha Levin <sashal@...nel.org>,
	patches@...ts.linux.dev, stable@...r.kernel.org,
	Eelco Chaudron <echaudro@...hat.com>,
	Simon Horman <horms@...nel.org>, aconole@...hat.com,
	netdev@...r.kernel.org, dev@...nvswitch.org
Subject: Re: [PATCH AUTOSEL 6.15 044/118] openvswitch: Stricter validation
 for the userspace action

On Thu, Jun 05, 2025 at 07:23:34AM -0700, Jakub Kicinski wrote:
> On Wed, 4 Jun 2025 10:28:09 +0200 Greg KH wrote:
> > Nothing that ends up on Linus's tree should not be allowed also to be in
> > a stable kernel release as there is no difference in the "rule" that "we
> > will not break userspace".
> > 
> > So this isn't an issue here, if you need/want to make parsing more
> > strict, due to bugs or whatever, then great, let's make it more strict
> > as long as it doesn't break anyone's current system.  It doesn't matter
> > if this is in Linus's release or in a stable release, same rule holds
> > for both.
> 
> For sure, tho, I think the question is inverted here. We seem to be
> discussing arguments why something should not be backported, rather
> than arguments why something should be backported. You seem to be
> saying that the barrier of entry to stable is lower than what we'd
> normally send to Linus for an -rc, which perhaps makes sense in other
> parts of the kernel, but in networking that doesn't compute.
> 
> We go by simple logic of deciding if something is a fix. 
> This is not a fix. Neither is this:
> https://lore.kernel.org/all/20250604005049.4147522-54-sashal@kernel.org/

Ok, then that's a valid reason to drop it, that is not what I was
thinking was happening here at all, sorry.

greg k-h