netdev - Re: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

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

Date: Tue, 12 Sep 2023 13:52:53 +0200
From: Florian Westphal <fw@...len.de>
To: Timo Sigurdsson <public_timo.s@...entcreek.de>
Cc: regressions@...ts.linux.dev, fw@...len.de, pablo@...filter.org,
	kadlec@...filter.org, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, netfilter-devel@...r.kernel.org,
	coreteam@...filter.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	sashal@...nel.org, carnil@...ian.org, 1051592@...s.debian.org
Subject: Re: Regression: Commit "netfilter: nf_tables: disallow rule addition
 to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in
 linux-stable

Timo Sigurdsson <public_timo.s@...entcreek.de> wrote:
> > Linux regression tracking (Thorsten Leemhuis) <regressions@...mhuis.info>
> > wrote:
> >> On 12.09.23 00:57, Pablo Neira Ayuso wrote:
> >> > Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
> >> > kernel check that rejects adding rules to bound chains. The incorrect
> >> > bytecode adds the chain binding, attach it to the rule and it adds the
> >> > rules to the chain binding. I have cherry-picked these three patches
> >> > for nftables v1.0.6 userspace and your ruleset restores fine.
> >> > [...]
> >> 
> >> Hmmmm. Well, this sounds like a kernel regression to me that normally
> >> should be dealt with on the kernel level, as users after updating the
> >> kernel should never have to update any userspace stuff to continue what
> >> they have been doing before the kernel update.
> > 
> > This is a combo of a userspace bug and this new sanity check that
> > rejects the incorrect ordering (adding rules to the already-bound
> > anonymous chain).
> > 
> 
> Out of curiosity, did the incorrect ordering or bytecode from the older userspace components actually lead to a wrong representation of the rules in the kernel or did the rules still work despite all that?

It works, but without the stricter behaviour userspace can trigger
memory corruption in the kernel. nftables userland will not trigger this.