netdev - Re: [PATCH] net: Fix invalid ip_route_output

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-prev] [thread-next>] [day] [month] [year] [list]

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