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

From: Simon Horman

Date: Mon Nov 02 2026 - 07:42:38 EST


On Sat, Oct 31, 2026 at 08:48:41PM +0800, Xia Yan wrote:
> 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.

Let's not get bogged down on this one. But FWIIW I think the decrement
is needed for the happy-path to work correctly. In particular, this line
which appears after the condition under discussion:

lse |= ttl << MPLS_LS_TTL_SHIFT;

>
> Reviewed-by: Xia Yan <yanxia@xxxxxxxxxxxxxxxxxxxx>

Reviewed-by: Simon Horman <horms@xxxxxxxxxx>