[PATCH net] net: skbuff: reject zero MPLS TTL before decrementing

[PATCH net] net: skbuff: reject zero MPLS TTL before decrementing

[Avi Weiss]

skb_mpls_dec_ttl() decrements the u8 TTL before checking whether it
expired. An incoming TTL of zero wraps to 255, causing the TC MPLS
dec_ttl action to pass an expired packet instead of dropping it.

Reject a zero TTL before the decrement while preserving the existing
behavior for TTL one and valid TTL values.

Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC")
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
---
 net/core/skbuff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 48f676411724..9b057cc9cbd3 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -6858,7 +6858,7 @@ int skb_mpls_dec_ttl(struct sk_buff *skb)
 
 	lse = be32_to_cpu(mpls_hdr(skb)->label_stack_entry);
 	ttl = (lse & MPLS_LS_TTL_MASK) >> MPLS_LS_TTL_SHIFT;
-	if (!--ttl)
+	if (!ttl || !--ttl)
 		return -EINVAL;
 
 	lse &= ~MPLS_LS_TTL_MASK;
-- 
2.43.0

Re: [PATCH net] net: skbuff: reject zero MPLS TTL before decrementing

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] net: skbuff: reject zero MPLS TTL before decrementing

[Xia Yan]

On 10/31/26 11:41, Avi Weiss wrote:
> skb_mpls_dec_ttl() decrements the u8 TTL before checking whether it
> expired. An incoming TTL of zero wraps to 255, causing the TC MPLS
> dec_ttl action to pass an expired packet instead of dropping it.
>
> Reject a zero TTL before the decrement while preserving the existing
> behavior for TTL one and valid TTL values.

Nice catch. I checked the wraparound against the C promotion and
conversion rules: with ttl being a u8, a zero TTL on the old path
decrements to 255 and the packet passes with a revived TTL. The new
check catches exactly that case, TTL one still returns -EINVAL, and
values of two and above are unchanged bit for bit.

The only in-tree caller I see is the TC dec_ttl action in
tcf_mpls_act(), which maps the error to TC_ACT_SHOT, so the rejected
packet is dropped. mpls_forward() already rejects TTL zero and one
(`dec.ttl <= 1`), so the two MPLS decrement paths now agree.

One minor observation, no change requested: `!ttl || !--ttl` is
equivalent to `ttl <= 1`, the form mpls_forward() uses. Stylistic
only; the patch is correct as posted.

Reviewed-by: Xia Yan <yanxia@cmss.chinamobile.com>