mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: 4ncienth@gmail.com
Cc: dsahern@kernel.org, idosch@nvidia.com, davem@davemloft.net,
	edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
	horms@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v3 2/3] ipv6: remove ifaddr from hash during ifdown list cleanup
Date: Sat, 10 Oct 2026 05:43:15 +0000	[thread overview]
Message-ID: <179161099539.434549.2238120015372268173@kernel.org> (raw)
In-Reply-To: <20261009054042.272944-3-4ncienth@gmail.com>

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message understates the bug being fixed.

--

ipv6: remove ifaddr from hash during ifdown list cleanup

This commit unhashes each non-kept address in addrconf_ifdown() just
before it is removed from the per-device list. That closes a race where
ipv6_add_addr() publishes an address after the Step 2 hash scan and
before the list snapshot.

Link: https://lore.kernel.org/r/20261004135117.GA206930@shredder

> The ifdown path then removes the address from the device list and drops
> its last reference while it is still linked in the hash. This triggers
> the WARN_ON() in inet6_ifa_finish_destroy().

[Severity: Low]
The code change looks correct. Does the commit message understate what
happens before this patch, though?

The WARN_ON() in inet6_ifa_finish_destroy() does not stop execution. In
this race, addrconf_ifdown() has already set ifa->state to
INET6_IFADDR_STATE_DEAD, so the "Freeing alive" early return is skipped
and the object is freed:

net/ipv6/addrconf.c:inet6_ifa_finish_destroy() {
	WARN_ON(!hlist_unhashed(&ifp->addr_lst));
    ...
	if (ifp->state != INET6_IFADDR_STATE_DEAD) {
		pr_warn("Freeing alive inet6 address %p\n", ifp);
		return;
	}

	kfree_rcu(ifp, rcu);
}

That leaves a freed ifa linked in net->ipv6.inet6_addr_lst. Later walks
of that hash chain would read freed memory. Examples include
ipv6_get_ifaddr() and ipv6_chk_addr() under RCU, ipv6_chk_same_addr()
from ipv6_add_addr_hash(), and the Step 2 scan in the next
addrconf_ifdown().

One way to reach it is ipv6_add_addr() called from RA processing through
addrconf_prefix_rcv_add_addr(), racing with a non-unregister
addrconf_ifdown().

> Unhashing before the list put prevents a stale hash entry.

Could the message say that the stale hash entry points to freed memory,
which makes this a use-after-free and not only a WARN?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261009054042.272944-1-4ncienth%40gmail.com

  reply	other threads:[~2026-10-10  5:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09  5:40 [PATCH net v3 0/3] ipv6: fix address publication races with addrconf_ifdown Daehyeon Ko
2026-10-09  5:40 ` [PATCH net v3 1/3] ipv6: serialize address publication with device teardown Daehyeon Ko
2026-10-10  5:43   ` netdev-bot+sashiko
2026-10-09  5:40 ` [PATCH net v3 2/3] ipv6: remove ifaddr from hash during ifdown list cleanup Daehyeon Ko
2026-10-10  5:43   ` netdev-bot+sashiko [this message]
2026-10-09  5:40 ` [PATCH net v3 3/3] ipv6: initialize temporary ifaddr before publication Daehyeon Ko
2026-10-10  5:43   ` netdev-bot+sashiko
2026-10-09  5:44 ` [PATCH net v3 0/3] ipv6: fix address publication races with addrconf_ifdown netdev-bot+sinfo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=179161099539.434549.2238120015372268173@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=4ncienth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®