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

[Ido Schimmel <idosch@nvidia.com>]

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.