netdev - Re: [PATCH net v2 2/3] net: ipv6: fix lwtunnel loops in ioam6, rpl and seg6

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 for Android: free password hash cracker in your pocket

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

Message-ID: <a375f869-9fc3-4a58-a81a-c9c8175463dd@uliege.be>
Date: Thu, 13 Feb 2025 23:51:49 +0100
From: Justin Iurman <justin.iurman@...ege.be>
To: Ido Schimmel <idosch@...sch.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, dsahern@...nel.org,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
 Alexander Aring <alex.aring@...il.com>, David Lebrun <dlebrun@...gle.com>
Subject: Re: [PATCH net v2 2/3] net: ipv6: fix lwtunnel loops in ioam6, rpl
 and seg6

On 2/13/25 14:28, Ido Schimmel wrote:
> On Tue, Feb 11, 2025 at 11:16:23PM +0100, Justin Iurman wrote:
>> When the destination is the same post-transformation, we enter a
>> lwtunnel loop. This is true for ioam6_iptunnel, rpl_iptunnel, and
>> seg6_iptunnel, in both input() and output() handlers respectively, where
>> either dst_input() or dst_output() is called at the end. It happens for
>> instance with the ioam6 inline mode, but can also happen for any of them
>> as long as the post-transformation destination still matches the fib
>> entry. Note that ioam6_iptunnel was already comparing the old and new
>> destination address to prevent the loop, but it is not enough (e.g.,
>> other addresses can still match the same subnet).
>>
>> Here is an example for rpl_input():
>>
>> dump_stack_lvl+0x60/0x80
>> rpl_input+0x9d/0x320
>> lwtunnel_input+0x64/0xa0
>> lwtunnel_input+0x64/0xa0
>> lwtunnel_input+0x64/0xa0
>> lwtunnel_input+0x64/0xa0
>> lwtunnel_input+0x64/0xa0
>> [...]
>> lwtunnel_input+0x64/0xa0
>> lwtunnel_input+0x64/0xa0
>> lwtunnel_input+0x64/0xa0
>> lwtunnel_input+0x64/0xa0
>> lwtunnel_input+0x64/0xa0
>> ip6_sublist_rcv_finish+0x85/0x90
>> ip6_sublist_rcv+0x236/0x2f0
>>
>> ... until rpl_do_srh() fails, which means skb_cow_head() failed.
>>
>> This patch prevents that kind of loop by redirecting to the origin
>> input() or output() when the destination is the same
>> post-transformation.
> 
> A loop was reported a few months ago with a similar stack trace:
> https://lore.kernel.org/netdev/2bc9e2079e864a9290561894d2a602d6@akamai.com/
> 
> But even with this series applied my VM gets stuck. Can you please check
> if the fix is incomplete?

Good catch! Indeed, seg6_local also needs to be fixed the same way.

Back to my first idea: maybe we could directly fix it in 
lwtunnel_input() and lwtunnel_output() to make our lives easier, but 
we'd have to be careful to modify all users accordingly. The users I'm 
100% sure that are concerned: ioam6 (output), rpl (input/output), seg6 
(input/output), seg6_local (input). Other users I'm not totally sure (to 
be checked): ila (output), bpf (input).

Otherwise, we'll need to apply the fix to each user concerned (probably 
the safest (best?) option right now). Any opinions?