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

On Mon, Aug 10, 2026 at 10:54:58AM +0200, Pimyn Girgis wrote:

On Mon, Aug 10, 2026 at 8:54 AM Ido Schimmel [off-list ref] wrote:

quoted

On Fri, Aug 07, 2026 at 03:13:00PM +0200, Pimyn Girgis wrote:

quoted

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 <redacted>

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.