Bug 1216024 - Kernel 5.14.21-150500.55.28-default breaks nftables ruleset loading
Summary: Kernel 5.14.21-150500.55.28-default breaks nftables ruleset loading
Status: IN_PROGRESS
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Leap 15.5
Hardware: Other Other
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: Michal Kubeček
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-07 19:14 UTC by Timo Sigurdsson
Modified: 2023-10-11 09:29 UTC (History)
3 users (show)

See Also:
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 (9.04 KB, text/plain)
2023-10-07 19:14 UTC, Timo Sigurdsson
Details

Note You need to log in before you can comment on or make changes to this bug.
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.