Re: [PATCH net v2] ipv4: prevent in_dev_get() from returning a dead in_device

[Eric Dumazet]

Le ven. 9 oct. 2026 à 08:21, Cen Zhang <zzzccc427@xxxxxxxxx> a écrit :
>
> in_dev_get() samples dev->ip_ptr under RCU and unconditionally
> increments the in_device reference count. Device teardown can clear
> the pointer and drop the last reference after the sample but before
> the increment. RCU keeps the allocation accessible during the lookup,
> but does not guarantee that a reference can still be acquired.
>
> Commit 9d40c84cf5bc ("net: devinet: Reduce refcount before grace period")
> moved the final put before the grace period. A zero-count increment now
> warns and saturates the count, but cannot cancel the RCU free that has
> already been queued. Returning that pointer lets callers access the
> allocation after leaving RCU, when it can have been freed.
>
> Use refcount_inc_not_zero() and return NULL if the reference cannot be
> acquired, following the in6_dev_get() fix in commit 0e243671bc7b ("ipv6:
> prevent in6_dev_get() from resurrecting inet6_dev"). A successful
> increment retains the object for the caller. Under RTNL, a published
> in_device still has a live reference, so reference acquisition is
> unchanged. Callers already account for a NULL dev->ip_ptr result.
>
> The RTM_GETNETCONF handler already checks for NULL and can keep
> RTNL_FLAG_DOIT_UNLOCKED. This fixes reference acquisition in the helper
> rather than serializing that one reader with teardown.
>
> KASAN report as below:
>
>   BUG: KASAN: slab-use-after-free in inet_netconf_fill_devconf+0x748/0x790
>   Read of size 4 at addr ffff88811d70b958 by task ip_core_fixture/498
>
>   Call Trace:
>     [...]
>     inet_netconf_fill_devconf+0x748/0x790
>     inet_netconf_get_devconf+0x41c/0xe40
>     rtnetlink_rcv_msg+0x7b9/0xce0
>     netlink_rcv_skb+0x133/0x390
>     [...]
>
>   Allocated by task 496:
>     [...]
>     inetdev_init+0x60/0x550
>     inetdev_event+0x71e/0x1780
>     [...]
>
>   Freed by task 0:
>     [...]
>     kfree+0x12b/0x530
>     in_dev_free_rcu+0x51/0x90
>     rcu_core+0x661/0x1d10
>     [...]
>
>   Last potentially related work creation:
>     [...]
>     __call_rcu_common.constprop.0+0x76/0xbd0
>     in_dev_finish_destroy+0x12e/0x190
>     inetdev_event+0xa37/0x1780
>     [...]

This is very confusing.
The changelog shows only the KASAN splat, which is really not that
interesting here.
The refcount_t: addition on 0 warning that must precede it would be
stronger evidence, as in the IPv6 commit.

So this looks like a modified kernel or something like AI hallucination ?
Please elaborate

pw-bot: cr