[syzbot] [kernel?] WARNING: ODEBUG bug in smpboot_thread_fn

2 views
Skip to first unread message

syzbot

unread,
May 4, 2026, 8:23:32 AM (3 days ago) May 4
to linux-...@vger.kernel.org, pet...@infradead.org, syzkall...@googlegroups.com, tg...@kernel.org
Hello,

syzbot found the following issue on:

HEAD commit: 6d35786de281 Merge tag 'for-linus' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=126bf21f980000
kernel config: https://syzkaller.appspot.com/x/.config?x=f2e8ebfec4636d32
dashboard link: https://syzkaller.appspot.com/bug?extid=ae231e0552fa77b26ea1
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b3ab34c4c807/disk-6d35786d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/03f465478178/vmlinux-6d35786d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/29d261604425/bzImage-6d35786d.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ae231e...@syzkaller.appspotmail.com

------------[ cut here ]------------
ODEBUG: free active (active state 0) object: ffff888033a47278 object type: timer_list hint: br_ip6_multicast_port_query_expired+0x0/0x380 net/bridge/br_multicast.c:-1
WARNING: lib/debugobjects.c:632 at debug_print_object lib/debugobjects.c:629 [inline], CPU#1: rcuc/1/28
WARNING: lib/debugobjects.c:632 at __debug_check_no_obj_freed lib/debugobjects.c:1116 [inline], CPU#1: rcuc/1/28
WARNING: lib/debugobjects.c:632 at debug_check_no_obj_freed+0x405/0x550 lib/debugobjects.c:1146, CPU#1: rcuc/1/28
Modules linked in:
CPU: 1 UID: 0 PID: 28 Comm: rcuc/1 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
RIP: 0010:debug_print_object lib/debugobjects.c:629 [inline]
RIP: 0010:__debug_check_no_obj_freed lib/debugobjects.c:1116 [inline]
RIP: 0010:debug_check_no_obj_freed+0x44a/0x550 lib/debugobjects.c:1146
Code: 89 44 24 20 e8 27 81 7f fd 48 8b 44 24 20 4c 8b 4d 00 4c 89 ef 48 c7 c6 a0 53 a7 8b 48 c7 c2 20 59 a7 8b 8b 0c 24 4d 89 f8 50 <67> 48 0f b9 3a 48 83 c4 08 4c 8b 6c 24 18 48 b9 00 00 00 00 00 fc
RSP: 0018:ffffc90000a2fa90 EFLAGS: 00010246
RAX: ffffffff89f32240 RBX: ffffffff99a8edc0 RCX: 0000000000000000
RDX: ffffffff8ba75920 RSI: ffffffff8ba753a0 RDI: ffffffff8f933740
RBP: ffffffff8b4f5380 R08: ffff888033a47278 R09: ffffffff8b4f6700
R10: dffffc0000000000 R11: ffffffff81b0c180 R12: ffff888033a47400
R13: ffffffff8f933740 R14: ffff888033a47000 R15: ffff888033a47278
FS: 0000000000000000(0000) GS:ffff888126279000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb873a4da08 CR3: 000000004cc78000 CR4: 00000000003526f0
Call Trace:
<TASK>
slab_free_hook mm/slub.c:2620 [inline]
slab_free mm/slub.c:6250 [inline]
kfree+0x13e/0x6c0 mm/slub.c:6565
kobject_cleanup lib/kobject.c:689 [inline]
kobject_release lib/kobject.c:720 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0x228/0x560 lib/kobject.c:737
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
rcu_core kernel/rcu/tree.c:2869 [inline]
rcu_cpu_kthread+0x99e/0x1470 kernel/rcu/tree.c:2957
smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
----------------
Code disassembly (best guess):
0: 89 44 24 20 mov %eax,0x20(%rsp)
4: e8 27 81 7f fd call 0xfd7f8130
9: 48 8b 44 24 20 mov 0x20(%rsp),%rax
e: 4c 8b 4d 00 mov 0x0(%rbp),%r9
12: 4c 89 ef mov %r13,%rdi
15: 48 c7 c6 a0 53 a7 8b mov $0xffffffff8ba753a0,%rsi
1c: 48 c7 c2 20 59 a7 8b mov $0xffffffff8ba75920,%rdx
23: 8b 0c 24 mov (%rsp),%ecx
26: 4d 89 f8 mov %r15,%r8
29: 50 push %rax
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 48 83 c4 08 add $0x8,%rsp
33: 4c 8b 6c 24 18 mov 0x18(%rsp),%r13
38: 48 rex.W
39: b9 00 00 00 00 mov $0x0,%ecx
3e: 00 fc add %bh,%ah


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Thomas Gleixner

unread,
May 6, 2026, 12:30:00 PM (yesterday) May 6
to syzbot, linux-...@vger.kernel.org, pet...@infradead.org, syzkall...@googlegroups.com, bri...@lists.linux.dev, Nikolay Aleksandrov, Ido Schimmel, net...@vger.kernel.org
On Mon, May 04 2026 at 05:23, syzbot wrote:

Cc'ed network/bridge people as that's clearly in their realm.

> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 6d35786de281 Merge tag 'for-linus' of git://git.kernel.org..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=126bf21f980000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f2e8ebfec4636d32
> dashboard link: https://syzkaller.appspot.com/bug?extid=ae231e0552fa77b26ea1
> compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/b3ab34c4c807/disk-6d35786d.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/03f465478178/vmlinux-6d35786d.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/29d261604425/bzImage-6d35786d.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+ae231e...@syzkaller.appspotmail.com
>
> ------------[ cut here ]------------
> ODEBUG: free active (active state 0) object: ffff888033a47278 object type: timer_list hint: br_ip6_multicast_port_query_expired+0x0/0x380 net/bridge/br_multicast.c:-1

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
An object which contains an active timer is RCU freed....

Thomas Gleixner

unread,
4:57 AM (9 hours ago) 4:57 AM
to syzbot, linux-...@vger.kernel.org, pet...@infradead.org, syzkall...@googlegroups.com, bri...@lists.linux.dev, Nikolay Aleksandrov, Ido Schimmel, net...@vger.kernel.org
On Wed, May 06 2026 at 18:29, Thomas Gleixner wrote:
> On Mon, May 04 2026 at 05:23, syzbot wrote:
>>
>> ------------[ cut here ]------------
>> ODEBUG: free active (active state 0) object: ffff888033a47278 object type: timer_list hint: br_ip6_multicast_port_query_expired+0x0/0x380 net/bridge/br_multicast.c:-1
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> An object which contains an active timer is RCU freed....

Unlike the other timer in the same object, the own_query timer is not
shut down in br_multicast_port_ctx_deinit()

Something kike the below.

Thanks,

tglx
---
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -2030,8 +2030,10 @@ void br_multicast_port_ctx_deinit(struct

#if IS_ENABLED(CONFIG_IPV6)
timer_delete_sync(&pmctx->ip6_mc_router_timer);
+ timer_delete_sync(&pmctx->ip6_own_query_timer);
#endif
timer_delete_sync(&pmctx->ip4_mc_router_timer);
+ timer_delete_sync(&pmctx->ip4_own_query_timer);

spin_lock_bh(&br->multicast_lock);
del |= br_ip6_multicast_rport_del(pmctx);

Ido Schimmel

unread,
1:30 PM (23 minutes ago) 1:30 PM
to Thomas Gleixner, syzbot, linux-...@vger.kernel.org, pet...@infradead.org, syzkall...@googlegroups.com, bri...@lists.linux.dev, Nikolay Aleksandrov, net...@vger.kernel.org
Thanks for the report and the fix. It looks correct, but it's unclear to
me which commit to blame.

AFAICT, the trace tells us that the timer is pending (not executing)
when the object that contains it is RCU freed. However, it shouldn't be
possible for the timer to be pending at this stage since it is
deactivated when the port multicast context is disabled and it is only
reactivated if the context is not disabled.

So, I see two options:

1. We did not disable port multicast context.

2. We did disable the port multicast context, but the timer somehow got
reactivated.

I will look into it...
Reply all
Reply to author
Forward
0 new messages