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

On Mon, Aug 10, 2026 at 8:54 AM Ido Schimmel <[email protected]> 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: [email protected]
> > Closes: https://syzkaller.appspot.com/bug?extid=ded267b328e950a7c0c4
> > Signed-off-by: Pimyn Girgis <[email protected]>
>
> 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
[email protected]