Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Abdifatah Suruur]

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

Willy, thanks for the guidance. I have Cc'd Florian (author of bb061d3) and
Pablo as you suggested.

Florian, Pablo,

Mainline closed this only as a side effect of bb061d3de4170741 ("netfilter:
nft_byteorder: remove multi-register support", 2026-05-12), which is marked
Cc: stable+noautosel and is not in 6.12.y.  Was it left out of stable because
it is not backportable, or because it was judged not worth backporting?

I verified the gap on 6.12.113: nft_byteorder_eval() writes len / size whole
elements, while nft_parse_register_store() marks DIV_ROUND_UP(len, 4) full
32-bit words as initialised.  With size 2 and len 1 the control plane marks
one word and eval writes none of it; a later load from another expression is
accepted and reads the uninitialised struct nft_regs slot in nft_do_chain().

To be precise about scope, since Willy rightly noted that distro kernels are
not the point: the official 6.12.y source itself has the unvalidated store.
With the default CONFIG_INIT_STACK_ALL_ZERO the register file is zeroed at
nft_do_chain() entry and the stale bytes are masked; with
CONFIG_INIT_STACK_NONE they are exposed.  nft_byteorder should not depend on
the stack-init configuration either way.  My SUSE run was only where I could
observe it.

Attached is a minimal format-patch against 6.12.113 that zeroes the
destination span the control plane marks as written.  It is semantically
neutral for existing rules and preserves multi-register support, unlike
backporting bb061d3's removal.  I have verified that it applies cleanly to
6.12.113; I can build and boot-test the patched kernel and provide the logs
if that helps.

If you agree, would you ack it for 6.12.y?  If you prefer the full bb061d3
removal or a different fix, I will follow your preference.  security@ is kept
in Cc for the stable-integration discussion, as Willy suggested.  I have read
Documentation/process/cve.rst and will use the documented CVE process; no
public disclosure has been made, and I ask that the thread stay private until
a fix is agreed.

Thanks,
Abdifatah Suruur
suruurism@gmail.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-netfilter-nft_byteorder-initialise-marked-destination-span.patch --]
[-- Type: text/x-patch, Size: 2256 bytes --]

From 83683beadd10ca6a81b9f78c0dd79c489c868ed8 Mon Sep 17 00:00:00 2001
From: Abdifatah Suruur <suruurism@gmail.com>
Date: Mon, 19 Oct 2026 01:15:27 +0300
Subject: [PATCH] netfilter: nft_byteorder: initialise the marked destination
 span

nft_byteorder_eval() writes only priv->len / priv->size whole elements,
while nft_parse_register_store() marks DIV_ROUND_UP(priv->len, 4) full
32-bit words as initialised.  For len/size combinations that do not fill
the last marked word -- for example size 2 with len 1, which writes no
element at all -- the control plane still accepts a later load of the
whole word from another expression.  That load reads stale bytes from
the struct nft_regs stack slot in nft_do_chain(), which is not
zero-initialised.

Mainline closed this incidentally in bb061d3de4170741 ("netfilter:
nft_byteorder: remove multi-register support") by removing the feature
that allowed partial multi-register stores.  That is a functional change
and was marked noautosel, so stable 6.12.y still accepts the same
len/size combinations and still marks the unwritten span.

Zero the span that the control plane marks as initialised before doing
the conversion.  This does not change the result of any existing rule;
it only removes the dependency on some other initialisation of the
register file.  The leak is masked when CONFIG_INIT_STACK_ALL_ZERO
zeroes nft_do_chain()'s regs, but nft_byteorder must not rely on that:
builds using CONFIG_INIT_STACK_NONE expose the stale bytes.

Since mainline no longer has the multi-register path after bb061d3,
this init fix is proposed for 6.12.y only.

Fixes: 14fb07130c7d ("netfilter: nf_tables: allow loads only when register is initialized")
Cc: stable@vger.kernel.org
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
---
 net/netfilter/nft_byteorder.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/netfilter/nft_byteorder.c b/net/netfilter/nft_byteorder.c
index 7448787..638f83a 100644
--- a/net/netfilter/nft_byteorder.c
+++ b/net/netfilter/nft_byteorder.c
@@ -33,6 +33,8 @@ void nft_byteorder_eval(const struct nft_expr *expr,
 	u16 *s16, *d16;
 	unsigned int i;
 
+	memset(dst, 0, DIV_ROUND_UP(priv->len, 4) * sizeof(u32));
+
 	s16 = (void *)src;
 	d16 = (void *)dst;
 
-- 
2.53.0

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Florian Westphal]

Abdifatah Suruur <suruurism@gmail.com> wrote:
> Mainline closed this only as a side effect of bb061d3de4170741 ("netfilter:
> nft_byteorder: remove multi-register support", 2026-05-12), which is marked
> Cc: stable+noautosel and is not in 6.12.y.  Was it left out of stable because
> it is not backportable, or because it was judged not worth backporting?

Because of potential nft -f restore.file failure.
Very unlikely (it requires a buggy nft version trying to load certain
		rules that won't work).

nft 1.1.1 (which has a fix for this...) is now 2 years old though.

I think its fine to backport bb061d3de4170741 to 6.12, but your explicit memset is fine too.

In case stable maintainers prefer the memset:

> Subject: [PATCH] netfilter: nft_byteorder: initialise the marked destination

Acked-by: Florian Westphal <fw@strlen.de>

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Abdifatah Suruur]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Hi Florian, stable,

Thanks for the explanation and the Ack.  The explicit memset patch is
attached with your Acked-by; it applies cleanly to 6.12.113.

Stable maintainers: would you prefer this minimal init patch or a backport
of bb061d3de4170741?  Either works from my side.  The memset preserves the
existing multi-register ABI and is the smaller change; Florian is fine with
either.

I will request a CVE via cve@kernel.org once this is queued, per the
documented process.

Thanks,
Abdifatah Suruur
suruurism@gmail.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-netfilter-nft_byteorder-initialise-marked-destination-span.patch --]
[-- Type: text/x-patch, Size: 2298 bytes --]

From 83683beadd10ca6a81b9f78c0dd79c489c868ed8 Mon Sep 17 00:00:00 2001
From: Abdifatah Suruur <suruurism@gmail.com>
Date: Mon, 19 Oct 2026 01:15:27 +0300
Subject: [PATCH] netfilter: nft_byteorder: initialise the marked destination
 span

nft_byteorder_eval() writes only priv->len / priv->size whole elements,
while nft_parse_register_store() marks DIV_ROUND_UP(priv->len, 4) full
32-bit words as initialised.  For len/size combinations that do not fill
the last marked word -- for example size 2 with len 1, which writes no
element at all -- the control plane still accepts a later load of the
whole word from another expression.  That load reads stale bytes from
the struct nft_regs stack slot in nft_do_chain(), which is not
zero-initialised.

Mainline closed this incidentally in bb061d3de4170741 ("netfilter:
nft_byteorder: remove multi-register support") by removing the feature
that allowed partial multi-register stores.  That is a functional change
and was marked noautosel, so stable 6.12.y still accepts the same
len/size combinations and still marks the unwritten span.

Zero the span that the control plane marks as initialised before doing
the conversion.  This does not change the result of any existing rule;
it only removes the dependency on some other initialisation of the
register file.  The leak is masked when CONFIG_INIT_STACK_ALL_ZERO
zeroes nft_do_chain()'s regs, but nft_byteorder must not rely on that:
builds using CONFIG_INIT_STACK_NONE expose the stale bytes.

Since mainline no longer has the multi-register path after bb061d3,
this init fix is proposed for 6.12.y only.

Fixes: 14fb07130c7d ("netfilter: nf_tables: allow loads only when register is initialized")
Cc: stable@vger.kernel.org
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Acked-by: Florian Westphal <fw@strlen.de>
---
 net/netfilter/nft_byteorder.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/netfilter/nft_byteorder.c b/net/netfilter/nft_byteorder.c
index 7448787..638f83a 100644
--- a/net/netfilter/nft_byteorder.c
+++ b/net/netfilter/nft_byteorder.c
@@ -33,6 +33,8 @@ void nft_byteorder_eval(const struct nft_expr *expr,
 	u16 *s16, *d16;
 	unsigned int i;
 
+	memset(dst, 0, DIV_ROUND_UP(priv->len, 4) * sizeof(u32));
+
 	s16 = (void *)src;
 	d16 = (void *)dst;
 
-- 
2.53.0

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Greg KH]

On Mon, Oct 19, 2026 at 09:08:41AM +0300, Abdifatah Suruur wrote:
> Hi Florian, stable,
> 
> Thanks for the explanation and the Ack.  The explicit memset patch is
> attached with your Acked-by; it applies cleanly to 6.12.113.
> 
> Stable maintainers: would you prefer this minimal init patch or a backport
> of bb061d3de4170741?  Either works from my side.  The memset preserves the
> existing multi-register ABI and is the smaller change; Florian is fine with
> either.

A full backport is always preferred for lots of reasons (long term
maintenance and proper tracking is the primary one.)

Please submit that and we will be glad to queue it up.

thanks,

greg k-h

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Pablo Neira Ayuso]

On Mon, Oct 19, 2026 at 09:08:41AM +0300, Abdifatah Suruur wrote:
> Hi Florian, stable,
> 
> Thanks for the explanation and the Ack.  The explicit memset patch is
> attached with your Acked-by; it applies cleanly to 6.12.113.
> 
> Stable maintainers: would you prefer this minimal init patch or a backport
> of bb061d3de4170741?  Either works from my side.  The memset preserves the
> existing multi-register ABI and is the smaller change; Florian is fine with
> either.
> 
> I will request a CVE via cve@kernel.org once this is queued, per the
> documented process.

Are you requesting a CVE for something that is fixed upstream?

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Sasha Levin]

> Stable maintainers: would you prefer this minimal init patch or a backport
> of bb061d3de4170741?  Either works from my side.  The memset preserves the
> existing multi-register ABI and is the smaller change; Florian is fine with
> either.

That commit has an explicit stable+noautosel tag, but now it needs to go into
stable?

-- 
Thanks,
Sasha

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Florian Westphal]

Sasha Levin <sashal@kernel.org> wrote:
> > Stable maintainers: would you prefer this minimal init patch or a backport
> > of bb061d3de4170741?  Either works from my side.  The memset preserves the
> > existing multi-register ABI and is the smaller change; Florian is fine with
> > either.
> 
> That commit has an explicit stable+noautosel tag, but now it needs to go into
> stable?

I did not consider this earth shattering enough to risk nft -f croaking
and refusing to load the ruleset.

The change has been upstream since 7.1, i.e. June and I am not aware of
regression reports.  If you prefer to wait longer: no problem...

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Abdifatah Suruur]

Hi Pablo,

I am not asking for a CVE for the upstream code, and I am not disputing
that bb061d3 fixes it in 7.1. I have not sent a cve@kernel.org request.

The only reason I mentioned a CVE is that 6.12.y still carries the
pre-bb061d3 multi-register path, and with CONFIG_INIT_STACK_NONE the
marked-but-unwritten destination word is exposed to a later nft load.
That is why I sent the 6.12.y backport rather than a mainline patch. On
the default CONFIG_INIT_STACK_ALL_ZERO builds the same oracle reads
zero, so the affected population is narrow.

If you and the CNA consider a stable-only infoleak that is already fixed
upstream not CVE-worthy, I will drop the request. The stable fix is the
part that matters to me. If you do want it tracked, I will follow the
documented process once the patch is queued.

Thanks,
Abdifatah Suruur

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Abdifatah Suruur]

Hi Sasha,

Yes. The stable+noautosel tag was about the risk of breaking rule load
with pre-1.1.0 nftables, not a judgement that the change should never
reach stable. Greg asked for the full backport for long-term maintenance
and proper tracking, Florian has explained the risk is limited to old
userspace and is fine with it, and the 6.12.y backport is the
[PATCH 6.12.y] message I sent in this thread at 10:08 +0300.

The security gap is stable-only: 6.12.y still has the multi-register
path and with CONFIG_INIT_STACK_NONE a later load can read the
uninitialised destination word. 6.6.y zeroes the register file, so I did
not find another affected stable branch.

If the automation declined the patch because of the noautosel tag,
please let me know whether you want it resent with this rationale or
under a different subject. The memset patch was only the alternative;
please disregard it in favour of the full backport.

Thanks,
Abdifatah Suruur

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Sasha Levin]

> Stable maintainers: would you prefer this minimal init patch or a backport
> of bb061d3de4170741?  Either works from my side.

Queued that commit for 6.12 and 6.18, thanks. 6.18 has the identical
leak.

-- 
Thanks,
Sasha

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Abdifatah Suruur]

Hi Pablo,

Yes.  The CVE would cover the vulnerability in released stable kernels, not
the upstream change itself.  bb061d3de4170741 is the upstream fix, but it was
not backported, and 6.12.y still leaks uninitialised stack words under
CONFIG_INIT_STACK_NONE; SUSE Leap 16 ships that configuration.

Sasha has now queued the full backport for both 6.12 and 6.18 (queue commits
d9a6f49f787e and 1eed0466672b).  I'll send the CVE request to cve@kernel.org
once it appears in a stable release, per the documented process.  Happy to
adjust if you'd prefer a different sequence.

Thanks,
Abdifatah Suruur
suruurism@gmail.com

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Greg KH]

On Wed, Oct 21, 2026 at 03:47:44PM +0300, Abdifatah Suruur wrote:
> Hi Pablo,
> 
> I am not asking for a CVE for the upstream code, and I am not disputing
> that bb061d3 fixes it in 7.1. I have not sent a cve@kernel.org request.
> 
> The only reason I mentioned a CVE is that 6.12.y still carries the
> pre-bb061d3 multi-register path, and with CONFIG_INIT_STACK_NONE the
> marked-but-unwritten destination word is exposed to a later nft load.
> That is why I sent the 6.12.y backport rather than a mainline patch. On
> the default CONFIG_INIT_STACK_ALL_ZERO builds the same oracle reads
> zero, so the affected population is narrow.
> 
> If you and the CNA consider a stable-only infoleak that is already fixed
> upstream not CVE-worthy, I will drop the request. The stable fix is the
> part that matters to me. If you do want it tracked, I will follow the
> documented process once the patch is queued.

What patch?  What request?

I'm totally lost here, sorry.

greg k-h

Re: [SECURITY] netfilter: nft_byteorder leaks uninitialised kernel stack on 6.12.y with CONFIG_INIT_STACK_NONE (CWE-457)

[Abdifatah Suruur]

Hi Greg,

Sorry for the confusion. The patch is the 6.12.y backport I sent to
stable@ on 2026-10-19:

  Subject: [PATCH 6.12.y] netfilter: nft_byteorder: remove multi-register support
  Message-ID: <179239371327.27230.3709565488726931662@gmail.com>
  Cc: you, Florian, Pablo, security@, Willy

It is a full backport of bb061d3de4170741 ("netfilter: nft_byteorder:
remove multi-register support") to 6.12.y, where the pre-bb061d3
multi-register path is still present.  It was sent after your reply:
"A full backport is always preferred ... Please submit that and we will
be glad to queue it up."

Sasha queued it on 2026-10-21 for 6.12 and 6.18 (queue commits
d9a6f49f787e0de7447462ee9f63de72ca9ec8c6 and
1eed0466672b84e1b50c149b7bd98886670f65a1).

There is no separate request pending: I have not sent anything to
cve@kernel.org.  My note to Pablo was only answering his question about
whether a CVE was being requested for an issue already fixed upstream.
I said I would follow the documented process after the stable fix ships,
and would drop the CVE request if the CNA considers it not CVE-worthy.
The stable fix is the part that matters.

No action needed from you; I am just waiting for the next 6.12.y release.

Thanks,
Abdifatah Suruur
suruurism@gmail.com