[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <179721c2-f471-0e26-9023-4742a5e2489c@google.com>
Date: Thu, 30 Mar 2023 08:42:56 +0100
From: Tudor Ambarus <tudordana@...gle.com>
To: Steffen Klassert <steffen.klassert@...unet.com>,
Hyunwoo Kim <v4bel@...ori.io>
Cc: Eric Dumazet <edumazet@...gle.com>,
Taehee Yoo <ap420073@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Dmitry Kozlov <xeb@...l.ru>,
David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
imv4bel@...il.com, Lee Jones <joneslee@...gle.com>
Subject: Re: [PATCH] net: Fix invalid ip_route_output_ports() call
Hi, Steffen!
On 3/24/23 09:57, Steffen Klassert wrote:
> On Tue, Mar 21, 2023 at 04:35:09AM -0700, Hyunwoo Kim wrote:
>> On Tue, Mar 21, 2023 at 04:19:25AM -0700, Eric Dumazet wrote:
>>> On Tue, Mar 21, 2023 at 4:14 AM Hyunwoo Kim <v4bel@...ori.io> wrote:
>>>>
>>>> I'm not sure what 'ip x p' means, as my understanding of XFRM is limited, sorry.
>>>
>>> Since your repro does not set up a private netns.
>>>
>>> Please install the iproute2 package (if not there already) and run the
>>> following command
>>>
>>> sudo ip x p
>>>
>>> man ip
>>>
>>> IP(8) Linux
>>> IP(8)
>>>
>>> NAME
>>> ip - show / manipulate routing, network devices, interfaces and tunnels
>>>
>>> SYNOPSIS
>>
>> This is the result of creating a new netns, running repro, and then running the ip x p command:
>> ```
>> src 255.1.0.0/0 dst 0.0.0.0/0
>> dir out priority 0
>> mark 0/0x6
>> tmpl src 0.0.0.0 dst 0.0.0.0
>> proto comp reqid 0 mode beet
>> level 16
>> tmpl src fc00:: dst e000:2::
>> proto ah reqid 0 mode tunnel
>> level 32
>> tmpl src ac14:14bb:: dst ac14:14fa::
>> proto route2 reqid 0 mode transport
>> level 3
>> tmpl src :: dst 2001::1
>> proto ah reqid 0 mode in_trigger
>> tmpl src ff01::1 dst 7f00:1::
>> proto comp reqid 0 mode transport
>> ```
>
> I plan to fix this with the patch below. With this, the above policy
> should be rejected. It still needs a bit of testing to make sure that
> I prohibited no valid usecase with it.
>
> ---
> Subject: [PATCH RFC ipsec] xfrm: Don't allow optional intermediate templates that
> changes the address family
>
> When an optional intermediate template changes the address family,
> it is unclear which family the next template should have. This can
> lead to misinterpretations of IPv4/IPv6 addresses. So reject
> optional intermediate templates on insertion time.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: Hyunwoo Kim <v4bel@...ori.io>
> Signed-off-by: Steffen Klassert <steffen.klassert@...unet.com>
> ---
> net/xfrm/xfrm_user.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
What's the status of this patch? I'm asking because LTS kernels are
affected and we'll have to fix them too. I tried searching for a related
patch on public ml archives and into the IPSEC repositories and I
couldn't find one.
Thanks!
ta
Powered by blists - more mailing lists