Re: Re: [PATCH] net: openvswitch: Fix the dead loop of MPLS parse

[Faicker Mo <faicker.mo@zenlayer.com>]

On 2025/5/20, 18:38, "Ilya Maximets" <i.maximets@ovn.org <mailto:i.maximets@ovn.org>> wrote:
> The idea of not failing the parsing is to allow forwarding the packet
> based on parsed ethernet header.  So, we shouldn't fail here.
> We're also keeping num_labels_mask at zero in this case, so it'll be
> an MPLS packet with zero labels and it should not be parsed further,
> but can still be forwarded.

num_labels_mask should keep the first max MPLS_LABEL_DEPTH labels.
This is a MPLS packet with max MPLS_LABEL_DEPTH labels to continue forwarding.

> But also, there is another overflow here that is actually causing an
> infinite loop - the label_count * MPLS_HLEN easily overflows u8, so
> the check_header() a few lines above doesn't work properly starting
> at 32 labels and doesn't break the loop. We need to switch the
> label_count back to size_t or other sufficiently large type to avoid
> this overflow and make the parsing end naturally when we hit the end
> of the packet.

No overflow with check_header()?

> With the type change we may still consider returning early, though it's
> not clear what the value we should aim for in this case. And we need to
> figure out what the skb_inner_network_header() should be in this case.

We may parse until the packet end to set the inner network header?set to 0 if fail.

> One other thing,

> For some reason the patch was not delivered to lore.kernel.org
> and is not available in netdev+bpf patchwork and not in lkml.org.
> Both of our replies are available in list archives.  The original
> email is available only via mail-archive, but it is ovs-dev and
> not the netdev list:
>  https://www.mail-archive.com/ovs-dev@openvswitch.org/msg94895.html>7C0d27725cb11d49f0b479a26ae758f26d%7C1%7C0%7C638833450887452972%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1DXkGXqyAYVUf9BxH45MGy4BGSNozuUQwrU0IP8t%2FLI%3D&reserved=0
> Same for v2.

> Is kernel.org blocking the sender somehow?  Does anyone know?

Sorry. This is my outlook web problem with html after the plain text body.