Re: [PATCH net] ipv6: ioam: add NULL check for idev in ipv6_hop_ioam()

[Ido Schimmel <idosch@nvidia.com>]

On Sun, May 17, 2026 at 08:30:59PM +0200, Justin Iurman wrote:
> Reported by Sashiko:
> 
> The function ipv6_hop_ioam() accesses
> __in6_dev_get(skb->dev)->cnf.ioam6_enabled without validating the returned
> idev pointer. Because addrconf_ifdown() can concurrently clear dev->ip6_ptr
> via RCU, __in6_dev_get() can return NULL during interface teardown, which
> could cause a NULL pointer dereference when processing an IOAM Hop-by-Hop
> option.
> 
> Let's add a check and use SKB_DROP_REASON_IPV6DISABLED accordingly.
> 
> Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace")
> Cc: stable@vger.kernel.org
> Signed-off-by: Justin Iurman <justin.iurman@gmail.com>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>

Note that Sashiko points out another pre-existing issue that looks
valid:

"
This problem wasn't introduced by this patch, but pre-exists in the
ipv6_hop_ioam() function. Is it possible for hdr->opt_len to be read after
the underlying buffer has been freed?

The hdr pointer is initialized to point into the skb's linear data buffer.
Later, the code calls skb_ensure_writable(), which might reallocate the buffer:

	if (skb_ensure_writable(skb, optoff + 2 + hdr->opt_len))
		goto drop;

	/* Trace pointer may have changed */
	trace = (struct ioam6_trace_hdr *)(skb_network_header(skb)
					   + optoff + sizeof(*hdr));

	ioam6_fill_trace_data(skb, ns, trace, true);

	ioam6_event(IOAM6_EVENT_TRACE, dev_net(skb->dev),
		    GFP_ATOMIC, (void *)trace, hdr->opt_len - 2);

If the skb is cloned or lacks sufficient linear headroom, skb_ensure_writable()
will invoke pskb_expand_head(), which reallocates the skb's data buffer and
frees the old one, invalidating pointers to it.

While the code recalculates the trace pointer immediately after the call to
skb_ensure_writable(), it fails to recalculate the hdr pointer.

Could the subsequent read of hdr->opt_len in ioam6_event() result in a
use-after-free read, potentially leading to an out-of-bounds read and kernel
memory information leak since the length controls how many bytes are copied
into a Netlink message?
"