All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	Timo Sigurdsson <public_timo.s@silentcreek.de>,
	kadlec@netfilter.org, fw@strlen.de, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, sashal@kernel.org, carnil@debian.org,
	1051592@bugs.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
Date: Tue, 12 Sep 2023 12:27:01 +0200	[thread overview]
Message-ID: <20230912102701.GA13516@breakpoint.cc> (raw)
In-Reply-To: <b30a81fa-6b59-4bac-b109-99a4dca689de@leemhuis.info>

Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.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).

nf_tables uses a transaction allor-nothing model, this means that any
error that occurs during a transaction has to be reverse/undo all the
pending changes.  This has caused a myriad of bugs already.

So while this can be theoretically fixed in the kernel I don't see
a sane way to do it.  Error unwinding / recovery from deeply nested
errors is already too complex for my taste.

> Can't the kernel somehow detect the incorrect bytecode and do the right
> thing(tm) somehow?

Theoretically yes, but I don't feel competent enough to do it, just look
at all the UaF bugs of the past month.


  parent reply	other threads:[~2023-09-12 10:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-11 21:37 Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable Timo Sigurdsson
2023-09-11 22:57 ` Pablo Neira Ayuso
2023-09-12  8:32   ` Linux regression tracking (Thorsten Leemhuis)
2023-09-12  9:15     ` Bug#1051592: Info received (Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable) Debian Bug Tracking System
2023-09-12 10:27     ` Florian Westphal [this message]
2023-09-12 11:47       ` Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable Timo Sigurdsson
2023-09-12 11:52         ` Florian Westphal
2023-09-29 11:46       ` Linux regression tracking (Thorsten Leemhuis)
2023-09-29 11:51         ` Bug#1051592: Info received (Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable) Debian Bug Tracking System
2023-09-12 11:39   ` Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable Timo Sigurdsson
2023-09-12 11:58     ` Pablo Neira Ayuso
2023-09-12 19:13     ` Salvatore Bonaccorso
2023-09-15 20:44       ` Timo Sigurdsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230912102701.GA13516@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=1051592@bugs.debian.org \
    --cc=carnil@debian.org \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kadlec@netfilter.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=public_timo.s@silentcreek.de \
    --cc=regressions@lists.linux.dev \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.