[PATCH] ipv6: prevent in6_dev_get() from resurrecting inet6_dev

[PATCH] ipv6: prevent in6_dev_get() from resurrecting inet6_dev

[David Lee]

in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally
increments its refcount. Device teardown can clear the pointer and drop
the last reference between these operations. The increment then
resurrects an object whose RCU free has already been queued, so callers
can use it after it is freed.

Use refcount_inc_not_zero() and return NULL when the object has already
reached zero. RCU keeps the memory accessible through the attempted
reference acquisition, and a successful increment pins the object for
the caller.

Fixes: 8814c4b53381 ("[IPV6] ADDRCONF: Convert addrconf_lock to RCU.")
Bug found and triaged by OpenAI Security Research and 
validated by Trail of Bits.

Assisted-by: Codex:gpt-5.6-sol gpt-5.5-cyber
Signed-off-by: Kyle Zeng <kylebot@openai.com>
---
Trail of Bits has a reproducer for this bug that triggers
a KASAN use-after-free and can share if needed.

 include/net/addrconf.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 8ced27a82..e67642459 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -405,8 +405,8 @@ static inline struct inet6_dev *in6_dev_get(const struct net_device *dev)
 
 	rcu_read_lock();
 	idev = rcu_dereference(dev->ip6_ptr);
-	if (idev)
-		refcount_inc(&idev->refcnt);
+	if (idev && !refcount_inc_not_zero(&idev->refcnt))
+		idev = NULL;
 	rcu_read_unlock();
 	return idev;
 }

Re: [PATCH] ipv6: prevent in6_dev_get() from resurrecting inet6_dev

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Friday, 31 July 2026 15:52:01 CEST David Lee wrote:
> Fixes: 8814c4b53381 ("[IPV6] ADDRCONF: Convert addrconf_lock to RCU.")
> Bug found and triaged by OpenAI Security Research and 
> validated by Trail of Bits.
> 
> Assisted-by: Codex:gpt-5.6-sol gpt-5.5-cyber
> Signed-off-by: Kyle Zeng <kylebot@openai.com>

1. weird text (advertisement) + newlines in the tags section which shouldn't be there
   https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
   (and all these tag/format related sections below)

2. author didn't sign off the patch (see below)

3. odd unrelated Signed-off-by without any obvious connection to 
   the patch

   - I actually would guess that Kyle Zeng <kylebot@openai.com> is the author 
     and David Lee removed its authorship (From: ) before sending the patch.
     But in its current form, David is claiming to be the author. And even
     when it is the case, David must still add the the non-Author SoB at the
     end.

Regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] ipv6: prevent in6_dev_get() from resurrecting inet6_dev

[Ido Schimmel]

In addition to the other process comments you got, subject prefix should
have been "[PATCH net]" ("[PATCH net v2]" now). See:

https://docs.kernel.org/process/maintainer-netdev.html

Get the process right with one patch, then send the rest.

On Fri, Jul 31, 2026 at 01:52:01PM +0000, David Lee wrote:
> in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally
> increments its refcount. Device teardown can clear the pointer and drop
> the last reference between these operations. The increment then
> resurrects an object whose RCU free has already been queued, so callers
> can use it after it is freed.
> 
> Use refcount_inc_not_zero() and return NULL when the object has already
> reached zero. RCU keeps the memory accessible through the attempted
> reference acquisition, and a successful increment pins the object for
> the caller.
> 
> Fixes: 8814c4b53381 ("[IPV6] ADDRCONF: Convert addrconf_lock to RCU.")
> Bug found and triaged by OpenAI Security Research and 
> validated by Trail of Bits.
> 
> Assisted-by: Codex:gpt-5.6-sol gpt-5.5-cyber
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> ---
> Trail of Bits has a reproducer for this bug that triggers
> a KASAN use-after-free and can share if needed.

Didn't you see an "addition on 0; use-after-free" trace before KASAN?
Please include it in the commit message.

Was the bug reproduced on an unpatched kernel?

Also, what about IPv4? in_dev_get() has the same structure and at least
inet_netconf_get_devconf() is calling it without holding RTNL.