[PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn()

[PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn()

[Pimyn Girgis]

Kernel warning messages emitted via pr_warn() already have the
appropriate log level (KERN_WARNING) and should not include manual
prefixes such as "BUG: " or "WARNING: ".

Explicit "BUG: " prefixes in log strings can mislead testing tools
like syzkaller, which scan kernel console output for "BUG: " to
identify kernel oopses, panics, and fatal conditions.

Remove the manual "BUG: " prefix from the pr_warn() call in
__ipv6_ifa_notify().

Fixes: 2d819d250a1393 ("ipv6: Handle missing host route in __ipv6_ifa_notify")
Reported-by: syzbot+ded267b328e950a7c0c4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ded267b328e950a7c0c4
Signed-off-by: Pimyn Girgis <pimyn@google.com>
---
 net/ipv6/addrconf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f6fa2715b450b..8c714b4c0a9ba 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -6318,7 +6318,7 @@ static void __ipv6_ifa_notify(int event, struct inet6_ifaddr *ifp)
 		if (ifp->rt && !rcu_access_pointer(ifp->rt->fib6_node)) {
 			ip6_ins_rt(net, ifp->rt);
 		} else if (!ifp->rt && (ifp->idev->dev->flags & IFF_UP)) {
-			pr_warn("BUG: Address %pI6c on device %s is missing its host route.\n",
+			pr_warn("Address %pI6c on device %s is missing its host route.\n",
 				&ifp->addr, ifp->idev->dev->name);
 		}
 
-- 
2.55.0.654.g21b8a5bc05-goog

Re: [PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn()

[Pimyn Girgis]

On Mon, Aug 10, 2026 at 8:54 AM Ido Schimmel <idosch@nvidia.com> wrote:
>
> On Fri, Aug 07, 2026 at 03:13:00PM +0200, Pimyn Girgis wrote:
> > Kernel warning messages emitted via pr_warn() already have the
> > appropriate log level (KERN_WARNING) and should not include manual
> > prefixes such as "BUG: " or "WARNING: ".
> >
> > Explicit "BUG: " prefixes in log strings can mislead testing tools
> > like syzkaller, which scan kernel console output for "BUG: " to
> > identify kernel oopses, panics, and fatal conditions.
> >
> > Remove the manual "BUG: " prefix from the pr_warn() call in
> > __ipv6_ifa_notify().
> >
> > Fixes: 2d819d250a1393 ("ipv6: Handle missing host route in __ipv6_ifa_notify")
> > Reported-by: syzbot+ded267b328e950a7c0c4@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=ded267b328e950a7c0c4
> > Signed-off-by: Pimyn Girgis <pimyn@google.com>
>
> I am able to reproduce this (there is no reproducer from syzbot, so I'm
> not sure if it's the same one) and will investigate if we can avoid
> getting into this state. If so, there wouldn't be any need to touch this
> message.

Hi Ido,

Thanks for looking into this!

Correct me if I'm misunderstanding the code comment above that check:

/*
* If the address was optimistic we inserted the route at the
* start of our DAD process, so we don't need to do it again.
* If the device was taken down in the middle of the DAD
* cycle there is a race where we could get here without a
* host route, so nothing to insert. That will be fixed when
* the device is brought up.
*/

It seems this state is somewhat expected/handled and otherwise
harmless. The main issue here is simply that pr_warn() includes the
literal string "BUG: ", which leads syzkaller to treat a non-fatal
warning as a critical kernel panic/crash.

>
>
> Currently busy with more pressing issues, so this will take a while.

Thanks again, and no rush. Whenever you have time to look into it!


--
Ⲡⲟⲓⲙⲏⲛ Ⲅⲉⲱⲣⲅⲓⲟⲥ - Pimyn Girgis
Software Engineer
Kernel Dynamic Analysis
pimyn@google.com

Re: [PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn()

[Ido Schimmel]

On Fri, Aug 07, 2026 at 03:13:00PM +0200, Pimyn Girgis wrote:
> Kernel warning messages emitted via pr_warn() already have the
> appropriate log level (KERN_WARNING) and should not include manual
> prefixes such as "BUG: " or "WARNING: ".
> 
> Explicit "BUG: " prefixes in log strings can mislead testing tools
> like syzkaller, which scan kernel console output for "BUG: " to
> identify kernel oopses, panics, and fatal conditions.
> 
> Remove the manual "BUG: " prefix from the pr_warn() call in
> __ipv6_ifa_notify().
> 
> Fixes: 2d819d250a1393 ("ipv6: Handle missing host route in __ipv6_ifa_notify")
> Reported-by: syzbot+ded267b328e950a7c0c4@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=ded267b328e950a7c0c4
> Signed-off-by: Pimyn Girgis <pimyn@google.com>

I am able to reproduce this (there is no reproducer from syzbot, so I'm
not sure if it's the same one) and will investigate if we can avoid
getting into this state. If so, there wouldn't be any need to touch this
message.

Currently busy with more pressing issues, so this will take a while.

Re: [PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn()

[Ido Schimmel]

On Mon, Aug 10, 2026 at 10:54:58AM +0200, Pimyn Girgis wrote:
> On Mon, Aug 10, 2026 at 8:54 AM Ido Schimmel <idosch@nvidia.com> wrote:
> >
> > On Fri, Aug 07, 2026 at 03:13:00PM +0200, Pimyn Girgis wrote:
> > > Kernel warning messages emitted via pr_warn() already have the
> > > appropriate log level (KERN_WARNING) and should not include manual
> > > prefixes such as "BUG: " or "WARNING: ".
> > >
> > > Explicit "BUG: " prefixes in log strings can mislead testing tools
> > > like syzkaller, which scan kernel console output for "BUG: " to
> > > identify kernel oopses, panics, and fatal conditions.
> > >
> > > Remove the manual "BUG: " prefix from the pr_warn() call in
> > > __ipv6_ifa_notify().
> > >
> > > Fixes: 2d819d250a1393 ("ipv6: Handle missing host route in __ipv6_ifa_notify")
> > > Reported-by: syzbot+ded267b328e950a7c0c4@syzkaller.appspotmail.com
> > > Closes: https://syzkaller.appspot.com/bug?extid=ded267b328e950a7c0c4
> > > Signed-off-by: Pimyn Girgis <pimyn@google.com>
> >
> > I am able to reproduce this (there is no reproducer from syzbot, so I'm
> > not sure if it's the same one) and will investigate if we can avoid
> > getting into this state. If so, there wouldn't be any need to touch this
> > message.
> 
> Hi Ido,
> 
> Thanks for looking into this!
> 
> Correct me if I'm misunderstanding the code comment above that check:
> 
> /*
> * If the address was optimistic we inserted the route at the
> * start of our DAD process, so we don't need to do it again.
> * If the device was taken down in the middle of the DAD
> * cycle there is a race where we could get here without a
> * host route, so nothing to insert. That will be fixed when
> * the device is brought up.
> */
> 
> It seems this state is somewhat expected/handled and otherwise
> harmless. The main issue here is simply that pr_warn() includes the
> literal string "BUG: ", which leads syzkaller to treat a non-fatal
> warning as a critical kernel panic/crash.

The comment refers to the case where the device is down, but the warning
fires when the device is up. According to the blamed commit, the state
where the warning fires should be impossible to reach: "Add a warning if
the host route is missing AND the device is up; this is a situation that
should never happen". I guess that is why "BUG: " was used.

I have a reproducer that always ends up in this state, so it's not
impossible to reach. I need to see if we can avoid ending up in this
state, and then it should be fine to keep the message since it should
never fire unless there's an actual bug.

Re: [PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn()

[AnishMulay]

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.

Anish

Re: [PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn()

[Ido Schimmel]

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.