Re: [PATCH net v3] ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv()

[Hangbin Liu <hangbin.liu@linux.dev>]

Hi Andrea,
On Thu, Sep 17, 2026 at 07:41:28PM +0200, Andrea Mayer wrote:
> On Tue, 15 Sep 2026 20:24:22 +0800
> Hangbin Liu <hangbin.liu@linux.dev> wrote:
> 
> > On Tue, Sep 15, 2026 at 02:03:12PM +0800, Hangbin Liu wrote:
> > > Hi Andrea,
> > > 
> > > While reviewing the SRv6 code, I noticed you added an `idev` check in
> > > `ipv6_rthdr_rcv()`. I’m wondering whether it makes sense to also halt
> > > processing for `IPV6_SRCRT_TYPE_2` when `!idev`, given that IPv6 is
> > > disabled on that device.
> > > 
> > > If so, could we drop the skb early at the entry point of `ipv6_rthdr_rcv()`?
> > > The downside is that subsequent processing and `__IP6_INC_STATS()` would be
> > > skipped.
> > 
> > Oh, another behavior change. At present, if !idev, we can still process the
> > IPV6_SRCRT_TYPE_2 message. And the process will be skipped if we return early.
> > I'm not sure if this kind of change is acceptable or not in kernel.
> > 
> > But on the other hand, is it correct to accept and forward SRCRT Type 2
> > packets on device that IPv6 is disabled?
> > 
> > Thanks
> > Hangbin
> 
> Hi Hangbin,
> 
> One case is when IPv6 is already disabled as the packet arrives:
> ip6_rcv_core() drops the packet before ipv6_rthdr_rcv().
> The other is the transient window: dev->ip6_ptr can be cleared after
> that check, and ipv6_rthdr_rcv() can then find idev NULL.
> In that window the TYPE_2 path can run without idev. ipv6_srh_rcv() and
> ipv6_rpl_srh_rcv() cannot: they read idev->cnf. That is why the check
> sits before those two calls.

Thanks for your reply. So in fact, if IPv6 is disabled on an interface,
*all* SRCRT types get dropped in ip6_rcv_core(). The idev check inside
ipv6_rthdr_rcv() exists to close this transient window.

> 
> On the counters: __IP6_INC_STATS() goes through _DEVINC(), which skips
> the per-device bump when idev is NULL and still increments the per-net one.
> Stopping TYPE_2 in that window as well is a behaviour change, and I think
> it would need a reason of its own.

My understanding is that handling TYPE_2 within that window is also mismatched
with ip6_rcv_core(), theoretically it should not be processed.

However, since there is no harm for TYPE_2 with the current code. We can
retain the existing behavior unless someone reports issues, or until I have
time to restructure this function.

Thanks
Hangbin