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: Mon, 28 Sep 2026 19:35:28 +0300 [thread overview]
Message-ID: <20260928163528.GA568589@shredder> (raw)
In-Reply-To: <20260927175134.1909-1-anishm7030@gmail.com>
On Sun, Sep 27, 2026 at 01:51:34PM -0400, AnishMulay wrote:
> On Wed, Sep 09, 2026 at 02:56:55PM +0300, Ido Schimmel wrote:
> > 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 [...]
> >
> > 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:
> >
> > [...]
> > - if (!unregister && !idev->cnf.disable_ipv6) {
> > + if (!unregister && !idev->cnf.disable_ipv6 &&
> > + dev->mtu >= IPV6_MIN_MTU) {
> >
> > Regenerating the route in this case is more complexity for a case that
> > nobody is hitting other than fuzzers.
>
> No, mine does not touch MTU at all. dev->mtu stays above 1280 the whole
> time. My trigger is a second addrconf_ifdown() racing the pending
> addrconf_dad_work from an earlier up, both inside a single "ip link set
> lo up" call (that fires both NETDEV_UP and NETDEV_CHANGE through
> addrconf_notify()). The route gets deleted, the notifier gets skipped,
> and the async work later runs with ifp->rt NULL.
Please share your reproducer. Earlier in the thread you said you're
working on [1]. I asked Claude to translate the syz reproducer to bash
and it came up with [2]. It does set an MTU below the minimum on the
loopback device. I verified that the issue is reproduced without my
patch and doesn't reproduce with my patch.
syzbot was not able to test my patch because of some issue on its end.
[1] https://syzkaller.appspot.com/bug?extid=57f410c9a4f8d7a441d6
[2]
#!/bin/bash
# syzbot 57f410c9a4f8d7a441d6 as iproute2. Run in a fresh netns so the
# group-wide MTU change only reaches lo.
ip netns add syz
ns="ip netns exec syz"
$ns ip link set dev lo up
# 1st sendmsg: RTM_NEWLINK, no ifindex, IFLA_GROUP=0, IFLA_MTU=68
# Walks group 0 in registration order; lo is first, so it is already
# at 68 when a later fallback tunnel (sit0, min_mtu 1280) makes the
# whole request return -EINVAL. syzkaller ignores that, so do we.
# -> rtnl_group_changelink() -> do_setlink() on every group-0 device
$ns ip link set group 0 mtu 68 2>/dev/null
$ns ip -d link show dev lo | grep -ow "mtu [0-9]*"
# write(.../conf/all/keep_addr_on_down, "1")
$ns sysctl -wq net.ipv6.conf.all.keep_addr_on_down=1
# "repeat":true — the whole program loops; the warning is a race between
# the DAD work queued by fixup_permanent_addr() and the tail
# addrconf_ifdown() in the same NETDEV_UP, so it needs a few iterations.
for i in $(seq 1 20); do
# 2nd sendmsg: RTM_NEWADDR 2001::fb/64 dev lo, no NLM_F_EXCL
$ns ip -6 address replace 2001::fb/64 dev lo
# SIOCSIFFLAGS lo 0x1, then SIOCSIFFLAGS lo 0x0
$ns ip link set dev lo up
$ns ip link set dev lo down
done
echo "warnings: $(dmesg | grep -c 'missing its host route')"
$ns ip -6 address show dev lo
$ns ip -6 route show table local
ip netns del syz
prev parent reply other threads:[~2026-09-28 16:35 UTC|newest]
Thread overview: 8+ 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
2026-09-27 17:51 ` AnishMulay
2026-09-28 16:35 ` 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=20260928163528.GA568589@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.