Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: stable@vger.kernel.org
Cc: Sam Dlinn <sledge@meta.com>, edumazet@kernel.org, pablo@netfilter.org
Subject: [6.18.y request] netfilter: restrict payload mangling
Date: Wed, 4 Nov 2026 12:51:49 +0100	[thread overview]
Message-ID: <auscVa1zQMqoTxhq@strlen.de> (raw)

Hi Sasha, Greg,

Could you please pick up following commits for 6.18.x kernel?

Sam Dlinn reports just another heap OOB + container escape.
Root cause is that many parts of network stack rely on network/transport
headers not changing after their validation.

One way to alter them post-validation is via netfilter: userspace
queueing and payload rewrite via nf_tables.

These patches:
1. Disable nfqueue and nft payload rewrites in user namespaces
2. Restrict rewrites to header fields deemed safe, e.g.
stateless NAT / ip address rewrites are still possible in normal
network namespaces.

None of these patches had Cc stable because they intentionally
break existing features.

I checked:

1. they apply cleanly in this order to 6.18.x stable
2. netfilter kselftests still pass
3. nftables.git shell tests pass (minus one unrelated error that
   is also there without them).

968cc2c96390 ("netfilter: disable payload mangling in userns")
3744b0964d52 ("ipv6: Implement limits on extension header parsing") [1]
54f34607d184 ("netfilter: nfnetlink_queue: restrict writes to network header")
3785091c6c16 ("netfilter: nft_meta: add double-tagged vlan and pppoe support") [2]
df07998dfd40 ("netfilter: nftables: restrict linklayer and network header writes")
c3716a3c4346 ("netfilter: nftables: restrict checkum update offset")
112e447d17f7 ("netfilter: validate L4 headers after userspace packet writes")
c2226f0c7fe9 ("netfilter: nft_payload: restrict checksum offsets to known values")
63bac0278603 ("netfilter: nf_tables: fix netdev hook allocation memleak with dormant tables") [3]

[1] Is a dependency, it adds the IP6_MAX_EXT_HDRS_CNT define used
    in 'netfilter: nfnetlink_queue: restrict writes to network header'.

[2] Is a dependency, it adds the 'ethertype' field used in the patch
    coming afterwards.  If you don't like that, I can try to mangle
    the 'linklayer and network header writes' patch to use
    skb->protocol instead.

[3] is unrelated, while running the nftables tests kmemleak reported
    a splat that is fixed by that patch.

             reply	other threads:[~2026-11-04 11:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 11:51 Florian Westphal [this message]
2026-11-04 15:03 ` [6.18.y request] netfilter: restrict payload mangling Sasha Levin

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=auscVa1zQMqoTxhq@strlen.de \
    --to=fw@strlen.de \
    --cc=edumazet@kernel.org \
    --cc=pablo@netfilter.org \
    --cc=sledge@meta.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox