From: Simon Horman <horms@kernel.org>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: netdev@vger.kernel.org, stable@vger.kernel.org,
shaos <shawnq1@163.com>, "David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>, Jiri Pirko <jiri@resnulli.us>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Victor Nogueira <victor@mojatatu.com>,
Tom Goff <thomas.goff@boeing.com>
Subject: Re: [PATCH net v3 1/4] net/sched: act_ife: encode configured zero metadata values
Date: Mon, 9 Nov 2026 16:20:18 +0000 [thread overview]
Message-ID: <20261109162018.GM18859@horms.kernel.org> (raw)
In-Reply-To: <SER-NSBD.v3.r0.20261103064310-1@mojatatu.com>
On Tue, Nov 03, 2026 at 06:50:29AM -0500, Jamal Hadi Salim wrote:
> Reported by shaos <shawnq1@163.com> with a reproducer for the 32-bit
> case, which was reproduced and verified in our test environment.
>
> The issue:
> ife_check_meta_u32() and ife_check_meta_u16() both reserve eight bytes
> of metadata for a configured value even when that value is zero, but the
> matching encoder returns without calling ife_tlv_meta_encode(). The
> encoder therefore writes neither the TLV header nor its value, while the
> enclosing IFE length still includes the reserved bytes, exposing stale
> skb headroom contents to the peer.
>
> The 32-bit helper has been present since the IFE action was introduced
> (v4.6); the 16-bit helper was added with the 16-bit metadata helpers used
> by the skbtcindex callback (v4.9). Both defects predate the oldest
> supported stable kernel (5.10), so they are fixed together in this patch.
> Each hunk keeps its own Fixes: tag for provenance.
>
> The fix:
> Encode any configured value, including zero; skip the TLV only when
> there is neither a configured nor a runtime value. The runtime fallback
> is unchanged.
>
> A raw TCA_IFE_METALST netlink request is needed to express the
> configured zero: the IFE_META_SKBMARK attribute carries four zero
> payload bytes for the u32 helper, and IFE_META_TCINDEX two zero payload
> bytes for the 16-bit helper (not an absent or zero-length attribute).
> Stock tc cannot build these requests; "use mark 0x0" emits no mark
> attribute and "allow mark" emits a zero-length one.
>
> Conditions to recreate the bug:
> CONFIG_NET_ACT_IFE=y, CONFIG_NET_IFE_SKBMARK=y,
> CONFIG_NET_IFE_SKBTCINDEX=y, CONFIG_NET_CLS_MATCHALL=y,
> CONFIG_NET_SCH_INGRESS=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y,
> CONFIG_VETH=y. In a fresh user and network namespace create a veth pair
> and attach clsact to the egress side. Install a matchall filter whose
> ife encode action carries a zero skb mark (or a zero tcindex) in
> TCA_IFE_METALST. Send a frame through the veth and inspect the IFE
> metadata in the received frame. The metadata region is eight bytes but
> holds neither a valid TLV header nor a value; it exposes prior headroom
> contents. Setting the value to a nonzero one does not trigger the leak.
> The namespace needs CAP_NET_ADMIN; no additional privilege is required.
> With the fix the zero TLVs are 0001000800000000 (u32) and
> 0005000600000000 (u16).
>
> Fixes: ef6980b6becb ("introduce IFE action")
> Fixes: 6a5d58b67e20 ("net sched ife action: add 16 bit helpers")
> Reported-by: shaos <shawnq1@163.com>
> Link: https://lore.kernel.org/netdev/20261022144739.61342-1-shawnq1@163.com/
> Cc: stable@vger.kernel.org
> Reviewed-by: Victor Nogueira <victor@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2026-11-09 16:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 11:50 [PATCH net v3 0/4] net/sched: fix short-skb metadata and namespace boundaries Jamal Hadi Salim
2026-11-03 11:50 ` [PATCH net v3 1/4] net/sched: act_ife: encode configured zero metadata values Jamal Hadi Salim
2026-11-09 16:20 ` Simon Horman [this message]
2026-11-03 11:50 ` [PATCH net v3 2/4] net/sched: act_ife: require a full Ethernet header on egress Jamal Hadi Salim
2026-11-07 14:50 ` netdev-bot+sashiko
2026-11-07 22:10 ` Jamal Hadi Salim
2026-11-09 16:20 ` Simon Horman
2026-11-03 11:50 ` [PATCH net v3 3/4] net/sched: sch_teql: reject qdiscs from another network namespace Jamal Hadi Salim
2026-11-07 14:50 ` netdev-bot+sashiko
2026-11-07 22:13 ` Jamal Hadi Salim
2026-11-09 16:20 ` Simon Horman
2026-11-10 18:23 ` [PATCH net v3 0/4] net/sched: fix short-skb metadata and namespace boundaries patchwork-bot+netdevbpf
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=20261109162018.GM18859@horms.kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shawnq1@163.com \
--cc=stable@vger.kernel.org \
--cc=thomas.goff@boeing.com \
--cc=victor@mojatatu.com \
/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