several fixes for ioam6, rpl and seg6 lwtunnels

As a follow up to commit 92191dd10730 ("net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels"), we also need a conditional dst cache on input for seg6_iptunnel and rpl_iptunnel to prevent dst ref loops (i.e., if the packet destination did not change, we may end up recording a reference to the lwtunnel in its own cache, and the lwtunnel state will never be freed).

Fixes a7a29f9c361f ("net: ipv6: add rpl sr tunnel")

Fixes af4a2209b134 ("ipv6: sr: use dst_cache in seg6_input")

Signed-off-by Justin Iurman <[email protected]>

Cc Alexander Aring <[email protected]>

Cc David Lebrun <[email protected]>

Quoted 7 lines · Justin Iurman

As a follow up to commit 92191dd10730 ("net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels"), we also need a conditional dst cache on input for seg6_iptunnel and rpl_iptunnel to prevent dst ref loops (i.e., if the packet destination did not change, we may end up recording a reference to the lwtunnel in its own cache, and the lwtunnel state will never be freed).

Quoted 5 lines

Fixes a7a29f9c361f ("net: ipv6: add rpl sr tunnel")

Fixes af4a2209b134 ("ipv6: sr: use dst_cache in seg6_input")

Signed-off-by Justin Iurman <[email protected]>

Cc Alexander Aring <[email protected]>

Cc David Lebrun <[email protected]>

Not an expert but was asked to take a look. Seems consistent with the output path and comparing the state address seems safe as it is only compared and never dereferenced after dropping the dst in the input path.

I would have probably split it into two patches to make it a bit easier to backport. 5.4.y needs the seg6 fix, but not the rpl one.

Reviewed-by Ido Schimmel <[email protected]>

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.

Fixes 8cb3bf8bff3c ("ipv6: ioam: Add support for the ip6ip6 encapsulation")

Fixes a7a29f9c361f ("net: ipv6: add rpl sr tunnel")

Fixes 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")

Signed-off-by Justin Iurman <[email protected]>

Cc Alexander Aring <[email protected]>

Cc David Lebrun <[email protected]>

---
  net/ipv6/ioam6_iptunnel.c |  6 ++----
  net/ipv6/rpl_iptunnel.c   | 10 ++++++++++
  net/ipv6/seg6_iptunnel.c  | 33 +++++++++++++++++++++++++++------
  3 files changed, 39 insertions(+), 10 deletions(-)

net/ipv6/ioam6_iptunnel.c +0 -3

index 2c383c12a431..6c61b306f2e9 100644
@@ -337,7 +337,6 @@ static int ioam6_do_encap(struct net *net, struct sk_buff *skb,
  static int ioam6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
  {
  	struct dst_entry *dst = skb_dst(skb), *cache_dst = NULL;
-	struct in6_addr orig_daddr;
  	struct ioam6_lwt *ilwt;
  	int err = -EINVAL;
  	u32 pkt_cnt;

@@ -352,8 +351,6 @@ static int ioam6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
  	if (pkt_cnt % ilwt->freq.n >= ilwt->freq.k)
  		goto out;
 
-	orig_daddr = ipv6_hdr(skb)->daddr;
-
  	local_bh_disable();
  	cache_dst = dst_cache_get(&ilwt->cache);
  	local_bh_enable();

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.

Quoted 28 lines · Justin Iurman

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

Quoted 5 lines

... 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/[email protected]/

But even with this series applied my VM gets stuck. Can you please check if the fix is incomplete?

Quoted 35 lines · Ido Schimmel

Quoted 28 lines · Justin Iurman

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

Quoted 5 lines

... 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.

Quoted 5 lines

A loop was reported a few months ago with a similar stack trace:
https://lore.kernel.org/netdev/[email protected]/

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?

Quoted 44 lines · Justin Iurman

Quoted 35 lines · Ido Schimmel

Quoted 28 lines · Justin Iurman

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

Quoted 5 lines

... 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.

Quoted 5 lines

A loop was reported a few months ago with a similar stack trace:
https://lore.kernel.org/netdev/[email protected]/

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.

Quoted 8 lines

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?

I audited the various lwt users and I agree with your analysis about which users seem to be effected by this issue.

I'm not entirely sure how you want to fix this in lwtunnel_{input,output}() given that only the input()/output() handlers of the individual lwt users are aware of both the old and new dst entries.

BTW, I noticed that bpf implements the xmit() hook in addition to input()/output(). I wonder if a loop is possible in the following case:

ip_finish_output2() <----+

	lwtunnel_xmit()                                          |
		bpf_xmit()                                       |
			// bpf program does not change           |
			// the packet and returns                |
			// BPF_LWT_REROUTE                       |
			bpf_lwt_xmit_reroute()                   |
				// unmodified packet resolves    |
				// the same dst entry            |
				dst_output()                     |
					ip_output() -------------+

Quoted 66 lines · Ido Schimmel

Quoted 44 lines · Justin Iurman

Quoted 35 lines · Ido Schimmel

Quoted 28 lines · Justin Iurman

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

Quoted 5 lines

... 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.

Quoted 5 lines

A loop was reported a few months ago with a similar stack trace:
https://lore.kernel.org/netdev/[email protected]/

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.

Quoted 8 lines

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?

I audited the various lwt users and I agree with your analysis about which users seem to be effected by this issue.

I'm not entirely sure how you want to fix this in lwtunnel_{input,output}() given that only the input()/output() handlers of the individual lwt users are aware of both the old and new dst entries.

BTW, I noticed that bpf implements the xmit() hook in addition to input()/output(). I wonder if a loop is possible in the following case:

ip_finish_output2() <----+

Quoted 10 lines

	lwtunnel_xmit()                                          |
		bpf_xmit()                                       |
			// bpf program does not change           |
			// the packet and returns                |
			// BPF_LWT_REROUTE                       |
			bpf_lwt_xmit_reroute()                   |
				// unmodified packet resolves    |
				// the same dst entry            |
				dst_output()                     |
					ip_output() -------------+

FWIW, verified that this is indeed the case. Reproducer:

$ cat lwt_xmit_repo.bpf.c
// SPDX-License-Identifier: GPL-2.0
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("lwt_xmit")
int repo(struct __sk_buff *skb)

{
         return BPF_LWT_REROUTE;
}
$ clang -O2 -target bpf -c lwt_xmit_repo.bpf.c -o lwt_xmit_repo.o
# ip link add name dummy1 up type dummy
# ip route add 192.0.2.0/24 nexthop encap bpf xmit obj ./lwt_xmit_repo.o sec lwt_xmit dev dummy1
# ping 192.0.2.1

Quoted 31 lines · Ido Schimmel

Quoted 30 lines · Justin Iurman

Quoted 29 lines · Ido Schimmel

Quoted 28 lines · Justin Iurman

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

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

... 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/[email protected]/

Quoted 6 lines

[...]

BTW, I noticed that bpf implements the xmit() hook in addition to input()/output(). I wonder if a loop is possible in the following case:

ip_finish_output2() <----+

Quoted 10 lines

	lwtunnel_xmit()                                          |
		bpf_xmit()                                       |
			// bpf program does not change           |
			// the packet and returns                |
			// BPF_LWT_REROUTE                       |
			bpf_lwt_xmit_reroute()                   |
				// unmodified packet resolves    |
				// the same dst entry            |
				dst_output()                     |
					ip_output() -------------+

FWIW, verified that this is indeed the case. Reproducer:

$ cat lwt_xmit_repo.bpf.c
// SPDX-License-Identifier: GPL-2.0
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("lwt_xmit")
int repo(struct __sk_buff *skb)

{
         return BPF_LWT_REROUTE;
}
$ clang -O2 -target bpf -c lwt_xmit_repo.bpf.c -o lwt_xmit_repo.o
# ip link add name dummy1 up type dummy
# ip route add 192.0.2.0/24 nexthop encap bpf xmit obj ./lwt_xmit_repo.o sec lwt_xmit dev dummy1
# ping 192.0.2.1

Quoted 44 lines · Justin Iurman

Quoted 35 lines · Ido Schimmel

Quoted 28 lines · Justin Iurman

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

Quoted 5 lines

... 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.

Quoted 5 lines

A loop was reported a few months ago with a similar stack trace:
https://lore.kernel.org/netdev/[email protected]/

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.

Quoted 8 lines

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?

I audited the various lwt users and I agree with your analysis about which users seem to be effected by this issue.

I'm not entirely sure how you want to fix this in lwtunnel_{input,output}() given that only the input()/output() handlers of the individual lwt users are aware of both the old and new dst entries.

Some lwtunnel users implement both lwt input and output handlers. If the post-transformation destination on input is the same, the output handler is also called and the same transformation is applied (again). Here are the users: ila, bpf, rpl, seg6. The first one (ila) does not need this fix, since it already implements a check to avoid such a duplicate. The second (bpf) may need this fix, but I'm not familiar with that code path and will keep it out of this patch. The two others (rpl and seg6) do need this patch.

Due to the ila implementation (as an example), we cannot fix the issue in lwtunnel_input() and lwtunnel_output() directly. Instead, we need to do it on a case-by-case basis. This patch fixes both rpl_iptunnel and seg6_iptunnel users. The fix re-uses skb->redirected in input handlers to notify corresponding output handlers that the transformation was already applied and to skip it. The "redirected" field seems safe to be used here.

Fixes a7a29f9c361f ("net: ipv6: add rpl sr tunnel")

Fixes 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")

Signed-off-by Justin Iurman <[email protected]>

---
 net/ipv6/rpl_iptunnel.c  | 14 ++++++++++++--
 net/ipv6/seg6_iptunnel.c | 16 +++++++++++++---
 2 files changed, 25 insertions(+), 5 deletions(-)

net/ipv6/rpl_iptunnel.c +0 -0

index dc004e9aa649..2dc1f2297e39 100644

Quoted 33 lines · Justin Iurman

Some lwtunnel users implement both lwt input and output handlers. If the post-transformation destination on input is the same, the output handler is also called and the same transformation is applied (again). Here are the users: ila, bpf, rpl, seg6. The first one (ila) does not need this fix, since it already implements a check to avoid such a duplicate. The second (bpf) may need this fix, but I'm not familiar with that code path and will keep it out of this patch. The two others (rpl and seg6) do need this patch.

Due to the ila implementation (as an example), we cannot fix the issue in lwtunnel_input() and lwtunnel_output() directly. Instead, we need to do it on a case-by-case basis. This patch fixes both rpl_iptunnel and seg6_iptunnel users. The fix re-uses skb->redirected in input handlers to notify corresponding output handlers that the transformation was already applied and to skip it. The "redirected" field seems safe to be used here.

Fixes a7a29f9c361f ("net: ipv6: add rpl sr tunnel")

Fixes 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")

Signed-off-by Justin Iurman <[email protected]>

---
  net/ipv6/rpl_iptunnel.c  | 14 ++++++++++++--
  net/ipv6/seg6_iptunnel.c | 16 +++++++++++++---
  2 files changed, 25 insertions(+), 5 deletions(-)

net/ipv6/rpl_iptunnel.c +0 -0

index dc004e9aa649..2dc1f2297e39 100644
@@ -208,6 +208,12 @@ static int rpl_output(struct net *net, struct sock *sk, struct sk_buff *skb)
  	struct rpl_lwt *rlwt;
  	int err;
 

net/ipv6/rpl_iptunnel.c static int rpl_output(struct net *net, struct sock *sk, struct sk_buff *skb) · line 212

Quoted 2 lines

net/ipv6/rpl_iptunnel.c +2 -0

+	/* Don't re-apply the transformation when rpl_input() already did it */
+	if (skb_is_redirected(skb)) {

This check looks false-positive prone, i.e. if packet lands on an LWT tunnel due to an tc redirect from another non lwt device.

On the flip side I don't see any good method to propagate the relevant information. A skb ext would work, but I would not call that a good method.