Re: [PATCH net] seg6: fix NULL deref in input_action_end_dx{4,6}_finish() after nf hook

[Andrea Mayer <andrea.mayer@uniroma2.it>]

On Thu, 30 Jul 2026 17:23:09 +0200
Pablo Neira Ayuso <pablo@netfilter.org> wrote:

> [snip]
>
> > For net, dropping is the safe choice. Before the fix, the same scenario
> > panics the kernel (NULL deref), so a clean drop is not a regression.
> > I will look at v2.
>
> I would go for dropping the packet too, it is a simple fix for this crash.
>
> > With the lwtstate preserved (e.g., the skb_ext approach), the existing
> > code already handles both cases. Indeed, End.DX4 does
> > nhaddr = slwt->nh4.s_addr ?: iph->daddr, so a configured nexthop takes
> > precedence over the rewritten address, while an unconfigured one lets
> > the DNAT destination drive the lookup. End.DX6 follows the same pattern
> > through seg6_lookup_nexthop.
>
> What is the usecase for a hook to clear lwtstate information?

Re-routing after NAT. DNAT changes the destination and the dst is dropped.
SNAT changes the source and, with a matching XFRM policy, the dst is
replaced. The lwtstate is not involved, it just lives on the dst.

seg6_local and seg6_iptunnel call NF_HOOK from inside lwtunnel processing,
and their okfns then read the per-route state from skb_dst(skb)->lwtstate.
The relevant part of the configuration that produces the crash:

  # SRv6 ingress node
  ip -4 route add 10.0.0.99/32 \
          encap seg6 mode encap segs fc00:12:100::6004 dev veth0

  # SRv6 egress node
  sysctl -w net.netfilter.nf_hooks_lwtunnel=1
  ip -6 route add fc00:12:100::6004/128 \
          encap seg6local action End.DX4 nh4 10.0.0.2 dev veth-t100
  iptables -t nat -A PREROUTING -d 10.0.0.99 \
          -j DNAT --to-destination 10.0.0.222

End.DX4 decapsulates the inner IPv4 packet, then runs the PRE_ROUTING chain
on it with input_action_end_dx4_finish() as the okfn. The packet enters the
chain with the dst of the SID route still attached. The DNAT rule matches,
so the dst is dropped, and the okfn then dereferences NULL. That dst is
where it reads the lwtstate holding the End.DX4 parameters, nh4 among them.

In seg6_iptunnel the same happens at POST_ROUTING, where the okfns are
seg6_input_core() and seg6_output_core(). With SNAT and a matching XFRM
policy they find a valid dst whose lwtstate is NULL.

In the current tree seg6_local and seg6_iptunnel are the only lwtunnels
that call NF_HOOK, so this is not a general lwtunnel problem. I think the
fix belongs on the SRv6 side.

Ciao,
Andrea