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

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

[Justin Iurman]

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>
---
 net/ipv6/exthdrs.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 03cbce842c1a..47c5502a34a2 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -910,16 +910,27 @@ static bool ipv6_hop_ra(struct sk_buff *skb, int optoff)
 
 static bool ipv6_hop_ioam(struct sk_buff *skb, int optoff)
 {
+	enum skb_drop_reason drop_reason;
 	struct ioam6_trace_hdr *trace;
 	struct ioam6_namespace *ns;
+	struct inet6_dev *idev;
 	struct ioam6_hdr *hdr;
 
+	drop_reason = SKB_DROP_REASON_IP_INHDR;
+
 	/* Bad alignment (must be 4n-aligned) */
 	if (optoff & 3)
 		goto drop;
 
+	/* Does the device still have IPv6 configuration? */
+	idev = __in6_dev_get(skb->dev);
+	if (!idev) {
+		drop_reason = SKB_DROP_REASON_IPV6DISABLED;
+		goto drop;
+	}
+
 	/* Ignore if IOAM is not enabled on ingress */
-	if (!READ_ONCE(__in6_dev_get(skb->dev)->cnf.ioam6_enabled))
+	if (!READ_ONCE(idev->cnf.ioam6_enabled))
 		goto ignore;
 
 	/* Truncated Option header */
@@ -972,7 +983,7 @@ static bool ipv6_hop_ioam(struct sk_buff *skb, int optoff)
 	return true;
 
 drop:
-	kfree_skb_reason(skb, SKB_DROP_REASON_IP_INHDR);
+	kfree_skb_reason(skb, drop_reason);
 	return false;
 }
 
-- 
2.34.1

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

[Ido Schimmel]

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?
"