All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: AnishMulay <anishm7030@gmail.com>
Cc: pimyn@google.com, dsahern@kernel.org, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	horms@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	syzbot+ded267b328e950a7c0c4@syzkaller.appspotmail.com
Subject: Re: [PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn()
Date: Wed, 9 Sep 2026 14:56:55 +0300	[thread overview]
Message-ID: <20260909115655.GA1344764@shredder> (raw)
In-Reply-To: <20260908043143.120335-1-anishm7030@gmail.com>

On Tue, Sep 08, 2026 at 12:31:43AM -0400, AnishMulay wrote:
> Hi Ido,
> 
> I ran into this same warning independently (different syzbot report,
> address 2001::fb rather than fc00::, extid 57f410c9a4f8d7a441d6) and
> ended up tracing it down before finding this thread.
> 
> The mechanism in my case: keep_addr_on_down is set, addrconf_ifdown()
> clears ifp->rt and deletes the route for the kept address but skips
> its notifier. On the following up, fixup_permanent_addr() allocates a
> new fib6_info and schedules addrconf_dad_work asynchronously instead
> of inserting the route itself. If a second addrconf_ifdown() for the
> same device runs before that work item gets to execute (I see this
> happen within a single "ip link set lo up" call, which drives both a
> NETDEV_UP and a NETDEV_CHANGE through addrconf_notify()), the fresh
> route gets torn down again with no notifier to re-arm anything. The
> work item then runs with ifp->rt NULL and nothing left to insert.
> 
> I have a patch that regenerates the route at that point instead of
> only warning, verified against a C reproducer translated from the
> syzbot repro (no warning, and the /128 route is present after the
> down/up cycle, across repeated runs). Since you mentioned you were
> looking into avoiding this state, I wanted to check before sending it,
> in case you already have something further along or a different angle
> on it. Happy to send what I have either way.

Does your reproducer rely on both keep_addr_on_down being set on the
loopback device and its MTU going below 1280?

The loopback device retains global addresses when this happens, unlike
any other device:

# sysctl -wq net.ipv6.conf.lo.keep_addr_on_down=1
# ip -6 address add 2001:db8:1::1/64 dev lo
# ip link set dev lo mtu 1000
# ip -6 address show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1000 qdisc noqueue state UNKNOWN group default qlen 1000
    inet6 2001:db8:1::1/64 scope global tentative
       valid_lft forever preferred_lft forever

# ip link add name dummy1 up type dummy
# sysctl -wq net.ipv6.conf.dummy1.keep_addr_on_down=1
# ip -6 address add 2001:db8:2::1/64 dev dummy1
# ip link set dev dummy1 mtu 1000
# ip -6 address show dev dummy1

And the local address (::1) is not restored when the MTU goes above the
minimum IPv6 MTU:

# ip link set dev lo mtu 2000
# ip -6 address show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 2000 qdisc noqueue state UNKNOWN group default qlen 1000
    inet6 2001:db8:1::1/64 scope global tentative
       valid_lft forever preferred_lft forever

So, given that this state is quite broken and unlikely to be used by
anyone other than fuzzers, I would like to simply align the loopback
behavior with other devices and avoid keeping its addresses when the MTU
goes below the minimum:

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 9d89be7e0544..2f7c872421b6 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3908,9 +3908,12 @@ static int addrconf_ifdown(struct net_device *dev, bool unregister)
 	}
 
 	/* combine the user config with event to determine if permanent
-	 * addresses are to be removed from address hash table
+	 * addresses are to be removed from address hash table. IPv6 cannot
+	 * operate below IPV6_MIN_MTU, so treat that like disable_ipv6 and do
+	 * not keep addresses without their host routes.
 	 */
-	if (!unregister && !idev->cnf.disable_ipv6) {
+	if (!unregister && !idev->cnf.disable_ipv6 &&
+	    dev->mtu >= IPV6_MIN_MTU) {
 		/* aggregate the system setting and interface setting */
 		int _keep_addr = READ_ONCE(net->ipv6.devconf_all->keep_addr_on_down);

Regenerating the route in this case is more complexity for a case that
nobody is hitting other than fuzzers.

      reply	other threads:[~2026-09-09 11:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 13:13 [PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn() Pimyn Girgis
2026-08-10  9:51 ` Ido Schimmel
2026-08-10  8:54   ` Pimyn Girgis
2026-08-10 10:40     ` Ido Schimmel
2026-09-08  4:31       ` AnishMulay
2026-09-09 11:56         ` Ido Schimmel [this message]

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=20260909115655.GA1344764@shredder \
    --to=idosch@nvidia.com \
    --cc=anishm7030@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pimyn@google.com \
    --cc=syzbot+ded267b328e950a7c0c4@syzkaller.appspotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.