Bug 1216024

Summary:	Kernel 5.14.21-150500.55.28-default breaks nftables ruleset loading
Product:	[openSUSE] openSUSE Distribution	Reporter:	Timo Sigurdsson <timo>
Component:	Kernel	Assignee:	Michal Kubeček <mkubecek>
Status:	IN_PROGRESS ---	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P5 - None	CC:	matthias.gerstner, mkubecek, tiwai
Version:	Leap 15.5
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	Test ruleset to trigger the bug with kernel 5.14.21-150500.55.28-default

Description Timo Sigurdsson 2023-10-07 19:14:32 UTC

Created attachment 869986 [details]
Test ruleset to trigger the bug with kernel 5.14.21-150500.55.28-default

Hi,

the upgrade to kernel 5.14.21-150500.55.28-default breaks nftables ruleset loading on my OpenSUSE Leap 15.5 installation.

My attached example configuration loads fine with kernel 5.14.21-150500.55.19-default, but with kernel 5.14.21-150500.55.28-default you will see lots of "operation not permitted" errors (please note: very simple rulesets will still load fine, you need a more complex testcase).

This is due to an upstream regression in Linux stable which I already observed on my Debian servers and reported here:
https://lore.kernel.org/stable/20230911213750.5B4B663206F5@dd20004.kasserver.com/

The offending commit is "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) which is to address CVE-2023-4147.
Pablo Neira Ayuso explained that this commit breaks ruleset loading with older nftables userspace components v1.0.6 and earlier because they produce incorrect bytecode (wrong order) which is refused by this new kernel check.

Pablo and Florian Westphal further explained that they don't see a way to deal with this regression in the kernel and suggest applying 3 cherry-picked patches to the nftables userspace tools, see here:
https://lore.kernel.org/stable/ZP+bUpxJiFcmTWhy@calendula/

Kind regards,

Timo

Comment 1 Takashi Iwai 2023-10-10 10:08:20 UTC

It looks like a side-effect of the backport of the fix for CVE-2023-4147.
Reassigned to Michal.

Comment 2 Michal Kubeček 2023-10-10 11:53:09 UTC

The way I understand Pablo's e-mail linked in the initial description, the
stricter check introduced in the CVE backport only revealed a bug in (older
version of) nft utility so that it should be rather solved by patching nft.
I'll take a closer look at the proposed solution but let's add nftables
package maintainer proactively.

Comment 3 Timo Sigurdsson 2023-10-10 18:28:09 UTC

(In reply to Michal Kubeček from comment #2)
> The way I understand Pablo's e-mail linked in the initial description, the
> stricter check introduced in the CVE backport only revealed a bug in (older
> version of) nft utility so that it should be rather solved by patching nft.

Yes. That's also the way Debian took eventually. They patched their nftables packages with the three patches provided by Pablo to solve this issue.

Comment 4 Matthias Gerstner 2023-10-11 09:29:57 UTC

So this should affect SLE-15-SP5 / Leap 15.5 and newer. Should I work on
maintenance updates already or is there anything else to check up on?

Please assign to me once I should start working on updates.