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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <FA285FD8-1F28-4682-A717-570E2B528EFB@zenlayer.com>
Date: Wed, 21 May 2025 04:10:32 +0000
From: Faicker Mo <faicker.mo@...layer.com>
To: Ilya Maximets <i.maximets@....org>, Eelco Chaudron <echaudro@...hat.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"ovs-dev@...nvswitch.org" <ovs-dev@...nvswitch.org>, "aconole@...hat.com"
	<aconole@...hat.com>, "davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org"
	<kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"horms@...nel.org" <horms@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "dev@...nvswitch.org" <dev@...nvswitch.org>
Subject: Re: Re: [PATCH] net: openvswitch: Fix the dead loop of MPLS parse


On 2025/5/20, 18:38, "Ilya Maximets" <i.maximets@....org <mailto:i.maximets@....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.