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

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

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.

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.

Thanks
Andrea