Re: [syzbot] WARNING: ODEBUG bug in route4_destroy

[Zhen Chen <chenzhen126@huawei.com>]

On 21/9/5 0:46, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    57f780f1c433 atlantic: Fix driver resume flow.
> git tree:       net
> console output: https://syzkaller.appspot.com/x/log.txt?x=162590a5300000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=765eea9a273a8879
> dashboard link: https://syzkaller.appspot.com/bug?extid=2e3efb5eb71cb5075ba7
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11979286300000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14391933300000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+2e3efb5eb71cb5075ba7@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> ODEBUG: activate active (active state 1) object type: rcu_head hint: 0x0
> WARNING: CPU: 0 PID: 8461 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
> Modules linked in:
> CPU: 0 PID: 8461 Comm: syz-executor318 Not tainted 5.14.0-rc7-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
> Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd e0 c8 e3 89 4c 89 ee 48 c7 c7 e0 bc e3 89 e8 f0 de 0d 05 <0f> 0b 83 05 95 53 92 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
> RSP: 0018:ffffc9000160efb0 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
> RDX: ffff8880224a8000 RSI: ffffffff815d85b5 RDI: fffff520002c1de8
> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
> R10: ffffffff815d23ee R11: 0000000000000000 R12: ffffffff898d3320
> R13: ffffffff89e3c3a0 R14: 0000000000000000 R15: ffffffff898d3320
> FS:  00007f00d3339700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f00d3318718 CR3: 0000000018f1d000 CR4: 00000000001506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  debug_object_activate+0x2da/0x3e0 lib/debugobjects.c:672
>  debug_rcu_head_queue kernel/rcu/rcu.h:176 [inline]
>  __call_rcu kernel/rcu/tree.c:3013 [inline]
>  call_rcu+0x2c/0x750 kernel/rcu/tree.c:3109
>  queue_rcu_work+0x82/0xa0 kernel/workqueue.c:1754
>  route4_queue_work net/sched/cls_route.c:272 [inline]
>  route4_destroy+0x4b9/0x9a0 net/sched/cls_route.c:299
>  tcf_proto_destroy+0x6a/0x2d0 net/sched/cls_api.c:297
>  tcf_proto_put+0x8c/0xc0 net/sched/cls_api.c:309
>  tcf_chain_flush+0x21a/0x360 net/sched/cls_api.c:615
>  tcf_block_flush_all_chains net/sched/cls_api.c:1016 [inline]
>  __tcf_block_put+0x15a/0x510 net/sched/cls_api.c:1178
>  tcf_block_put_ext net/sched/cls_api.c:1383 [inline]
>  tcf_block_put_ext net/sched/cls_api.c:1375 [inline]
>  tcf_block_put+0xde/0x130 net/sched/cls_api.c:1393
>  drr_destroy_qdisc+0x44/0x1d0 net/sched/sch_drr.c:458
>  qdisc_destroy+0xc4/0x4d0 net/sched/sch_generic.c:1025
>  qdisc_put+0xcd/0xe0 net/sched/sch_generic.c:1044
>  notify_and_destroy net/sched/sch_api.c:1006 [inline]
>  qdisc_graft+0xc7c/0x1260 net/sched/sch_api.c:1078
>  tc_modify_qdisc+0xba4/0x1a60 net/sched/sch_api.c:1674
>  rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5575
>  netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
>  netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
>  netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
>  netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929
>  sock_sendmsg_nosec net/socket.c:703 [inline]
>  sock_sendmsg+0xcf/0x120 net/socket.c:723
>  ____sys_sendmsg+0x6e8/0x810 net/socket.c:2394
>  ___sys_sendmsg+0xf3/0x170 net/socket.c:2448
>  __sys_sendmsg+0xe5/0x1b0 net/socket.c:2477
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x445ef9
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 11 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f00d3339308 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00000000004cb468 RCX: 0000000000445ef9
> RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000004
> RBP: 00000000004cb460 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000008 R11: 0000000000000246 R12: 00000000004cb46c
> R13: 000000000049b074 R14: 6d32cc5e8ead0600 R15: 0000000000022000
> 

This looks like  route4_destroy is deleting the 'fold' which has been freed by tcf_queue_work in route4_change. It means 'fold' is still in the table.
I have tested this patch on syzbot and it works well, but I am not sure whether it will introduce other issues...

diff --git a/net/sched/cls_route.c b/net/sched/cls_route.c
index a35ab8c27866..758c21f9d628 100644
--- a/net/sched/cls_route.c
+++ b/net/sched/cls_route.c
@@ -526,7 +526,7 @@ static int route4_change(struct net *net, struct sk_buff *in_skb,
 	rcu_assign_pointer(f->next, f1);
 	rcu_assign_pointer(*fp, f);
 
-	if (fold && fold->handle && f->handle != fold->handle) {
+	if (fold && f->handle != fold->handle) {
 		th = to_hash(fold->handle);
 		h = from_hash(fold->handle >> 16);
 		b = rtnl_dereference(head->table[th]);