general protection fault in fib6_purge_rt

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: ee28b30cbbe0 r8169: fix crash if CONFIG_DEBUG_SHIRQ is ena..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=10c76ba3400000
kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
dashboard link: https://syzkaller.appspot.com/bug?extid=a25307ad099309f1c2b9
compiler: gcc (GCC) 8.0.1 20180413 (experimental)

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

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

IPv6: ADDRCONF(NETDEV_UP): veth0_to_bridge: link is not ready
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 195 Comm: kworker/u4:3 Not tainted 4.20.0-rc6+ #227
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: netns cleanup_net
RIP: 0010:fib6_drop_pcpu_from net/ipv6/ip6_fib.c:920 [inline]
RIP: 0010:fib6_purge_rt+0x5ce/0x7e0 net/ipv6/ip6_fib.c:956
Code: 0f b6 35 99 f1 33 03 31 ff 44 89 f6 e8 bb b7 a0 fa 45 84 f6 0f 84 ec
00 00 00 e8 dd b6 a0 fa 49 8d 47 70 48 89 c2 48 c1 ea 03 <42> 80 3c 22 00
0f 85 b5 01 00 00 48 8b 8d e0 fe ff ff 48 89 c2 48
RSP: 0018:ffff8881d8cadf18 EFLAGS: 00010202
RAX: 0000000000003400 RBX: 0000000000000001 RCX: ffffffff86decea0
RDX: 0000000000000680 RSI: ffffffff86decd93 RDI: 0000000000000005
RBP: ffff8881d8cae048 R08: ffff8881d8ca05c0 R09: ffffed1036ea6e1d
R10: ffffed1036ea6e1d R11: ffff8881b75370ef R12: dffffc0000000000
R13: ffff8881b75370c0 R14: 0000000000000001 R15: 0000000000003390
FS: 0000000000000000(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000619570 CR3: 00000001c28ac000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
fib6_del_route net/ipv6/ip6_fib.c:1809 [inline]
fib6_del+0xbe0/0x12e0 net/ipv6/ip6_fib.c:1840
fib6_clean_node+0x44c/0x650 net/ipv6/ip6_fib.c:2002
fib6_walk_continue+0x4b1/0x8e0 net/ipv6/ip6_fib.c:1924
fib6_walk+0x95/0xf0 net/ipv6/ip6_fib.c:1972
fib6_clean_tree+0x21c/0x420 net/ipv6/ip6_fib.c:2051
__fib6_clean_all+0x235/0x440 net/ipv6/ip6_fib.c:2067
fib6_clean_all+0x2a/0x40 net/ipv6/ip6_fib.c:2078
rt6_sync_down_dev+0x17a/0x1b0 net/ipv6/route.c:4038
rt6_disable_ip+0x87/0x720 net/ipv6/route.c:4043
addrconf_ifdown+0x168/0x1650 net/ipv6/addrconf.c:3669
addrconf_notify+0x6de/0x2770 net/ipv6/addrconf.c:3594
notifier_call_chain+0x17e/0x380 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1733
call_netdevice_notifiers net/core/dev.c:1751 [inline]
dev_close_many+0x40e/0x860 net/core/dev.c:1503
rollback_registered_many+0x543/0x1250 net/core/dev.c:7991
unregister_netdevice_many+0xfa/0x4c0 net/core/dev.c:9119
default_device_exit_batch+0x43a/0x540 net/core/dev.c:9588
ops_exit_list.isra.5+0x105/0x160 net/core/net_namespace.c:156
cleanup_net+0x555/0xb10 net/core/net_namespace.c:551
process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153
worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
kthread+0x35a/0x440 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace 42ffb82098483a68 ]---
RIP: 0010:fib6_drop_pcpu_from net/ipv6/ip6_fib.c:920 [inline]
RIP: 0010:fib6_purge_rt+0x5ce/0x7e0 net/ipv6/ip6_fib.c:956
Code: 0f b6 35 99 f1 33 03 31 ff 44 89 f6 e8 bb b7 a0 fa 45 84 f6 0f 84 ec
00 00 00 e8 dd b6 a0 fa 49 8d 47 70 48 89 c2 48 c1 ea 03 <42> 80 3c 22 00
0f 85 b5 01 00 00 48 8b 8d e0 fe ff ff 48 89 c2 48
RSP: 0018:ffff8881d8cadf18 EFLAGS: 00010202
RAX: 0000000000003400 RBX: 0000000000000001 RCX: ffffffff86decea0
RDX: 0000000000000680 RSI: ffffffff86decd93 RDI: 0000000000000005
RBP: ffff8881d8cae048 R08: ffff8881d8ca05c0 R09: ffffed1036ea6e1d
R10: ffffed1036ea6e1d R11: ffff8881b75370ef R12: dffffc0000000000
R13: ffff8881b75370c0 R14: 0000000000000001 R15: 0000000000003390
FS: 0000000000000000(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000619570 CR3: 00000001c28ac000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
This bug 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 bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit: cf08baa2 Add linux-next specific files for 20190306
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12f6755f200000
kernel config: https://syzkaller.appspot.com/x/.config?x=c8b6073d992e8217
dashboard link: https://syzkaller.appspot.com/bug?extid=a25307ad099309f1c2b9
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: amd64
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16b2c56f200000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13b8890b200000

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

Started in network mode
Own node identity ac1414aa, cluster identity 4711
New replicast peer: 172.20.20.187
Enabled bearer <udp:syz1>, priority 10
Enabling of bearer <udp:syz1> rejected, already enabled

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN

CPU: 1 PID: 7821 Comm: syz-executor772 Not tainted 5.0.0-next-20190306 #4

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011

RIP: 0010:fib6_drop_pcpu_from net/ipv6/ip6_fib.c:924 [inline]
RIP: 0010:fib6_purge_rt+0x4b3/0x670 net/ipv6/ip6_fib.c:960
Code: 0f b6 35 5a f6 44 03 31 ff 44 89 f6 e8 a6 1c 5b fb 45 84 f6 0f 84 b3
00 00 00 e8 58 1b 5b fb 49 8d 7f 70 48 89 f8 48 c1 e8 03 <80> 3c 18 00 0f
85 64 01 00 00 48 89 f8 4d 8b 77 70 48 c1 e8 03 80
RSP: 0018:ffff8880a5a26e98 EFLAGS: 00010202
RAX: 000000000000000e RBX: dffffc0000000000 RCX: ffffffff861579a9
RDX: 0000000000000000 RSI: ffffffff861578d8 RDI: 0000000000000071
RBP: ffff8880a5a26ef0 R08: ffff88808f9a6300 R09: ffffed101406c2f6
R10: ffffed101406c2f5 R11: ffff8880a03617af R12: 0000000000000000
R13: ffff8880a0361780 R14: 0000000000000001 R15: 0000000000000001
FS: 00007fe8383f8700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00005612a363f110 CR3: 0000000093362000 CR4: 00000000001406e0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:

fib6_del_route net/ipv6/ip6_fib.c:1813 [inline]
fib6_del+0xac2/0x10a0 net/ipv6/ip6_fib.c:1844
fib6_clean_node+0x3a8/0x590 net/ipv6/ip6_fib.c:2006
fib6_walk_continue+0x495/0x900 net/ipv6/ip6_fib.c:1928
fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:1976
fib6_clean_tree+0xe0/0x120 net/ipv6/ip6_fib.c:2055
__fib6_clean_all+0x118/0x2a0 net/ipv6/ip6_fib.c:2071
fib6_clean_all+0x2b/0x40 net/ipv6/ip6_fib.c:2082
rt6_sync_down_dev+0x134/0x150 net/ipv6/route.c:4051
rt6_disable_ip+0x27/0x5f0 net/ipv6/route.c:4056
addrconf_ifdown+0xa2/0x1220 net/ipv6/addrconf.c:3705
addrconf_notify+0x19a/0x2260 net/ipv6/addrconf.c:3630
notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
call_netdevice_notifiers net/core/dev.c:1765 [inline]
dev_close_many+0x33f/0x6f0 net/core/dev.c:1508
rollback_registered_many+0x43b/0xfd0 net/core/dev.c:8161
rollback_registered+0x109/0x1d0 net/core/dev.c:8226
unregister_netdevice_queue net/core/dev.c:9273 [inline]
unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9266
unregister_netdevice include/linux/netdevice.h:2655 [inline]
__tun_detach+0xd5b/0x1000 drivers/net/tun.c:727
tun_detach drivers/net/tun.c:744 [inline]
tun_chr_close+0xe0/0x180 drivers/net/tun.c:3435
__fput+0x2e5/0x8d0 fs/file_table.c:278
____fput+0x16/0x20 fs/file_table.c:309
task_work_run+0x14a/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x90a/0x2fa0 kernel/exit.c:876
do_group_exit+0x135/0x370 kernel/exit.c:980
get_signal+0x399/0x1d50 kernel/signal.c:2577
do_signal+0x87/0x1940 arch/x86/kernel/signal.c:816
exit_to_usermode_loop+0x244/0x2c0 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x44bca9
Code: 5b 65 73 63 61 70 65 20 63 6f 6e 74 72 6f 6c 2d 63 68 61 72 61 63 74
65 72 73 5d 20 00 5b 64 72 6f 70 20 63 6f 6e 74 72 6f 6c <2d> 63 68 61 72
61 63 74 65 72 73 5d 20 00 5b 73 6c 61 73 68 65 73
RSP: 002b:00007fe8383f7cf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00000000006dec48 RCX: 000000000044bca9
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00000000006dec48
RBP: 00000000006dec40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dec4c
R13: 00007ffd4d27000f R14: 00007fe8383f89c0 R15: 000000000000002d
Modules linked in:
---[ end trace 9a88786341e68810 ]---
RIP: 0010:fib6_drop_pcpu_from net/ipv6/ip6_fib.c:924 [inline]
RIP: 0010:fib6_purge_rt+0x4b3/0x670 net/ipv6/ip6_fib.c:960
Code: 0f b6 35 5a f6 44 03 31 ff 44 89 f6 e8 a6 1c 5b fb 45 84 f6 0f 84 b3
00 00 00 e8 58 1b 5b fb 49 8d 7f 70 48 89 f8 48 c1 e8 03 <80> 3c 18 00 0f
85 64 01 00 00 48 89 f8 4d 8b 77 70 48 c1 e8 03 80
RSP: 0018:ffff8880a5a26e98 EFLAGS: 00010202
RAX: 000000000000000e RBX: dffffc0000000000 RCX: ffffffff861579a9
RDX: 0000000000000000 RSI: ffffffff861578d8 RDI: 0000000000000071
RBP: ffff8880a5a26ef0 R08: ffff88808f9a6300 R09: ffffed101406c2f6
R10: ffffed101406c2f5 R11: ffff8880a03617af R12: 0000000000000000
R13: ffff8880a0361780 R14: 0000000000000001 R15: 0000000000000001
FS: 00007fe8383f8700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00005612a363f110 CR3: 0000000093362000 CR4: 00000000001406e0

[syzbot]

syzbot has bisected this bug to:

commit 52dfae5c85a4c1078e9f1d5e8947d4a25f73dd81
Author: Jon Maloy <jon....@ericsson.com>
Date: Thu Mar 22 19:42:52 2018 +0000

tipc: obtain node identity from interface by default

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1116d2a3200000
start commit: 52dfae5c tipc: obtain node identity from interface by defa..
git tree: linux-next
final crash: https://syzkaller.appspot.com/x/report.txt?x=1316d2a3200000
console output: https://syzkaller.appspot.com/x/log.txt?x=1516d2a3200000

kernel config: https://syzkaller.appspot.com/x/.config?x=c8b6073d992e8217
dashboard link: https://syzkaller.appspot.com/bug?extid=a25307ad099309f1c2b9

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16b2c56f200000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13b8890b200000

Reported-by: syzbot+a25307...@syzkaller.appspotmail.com
Fixes: 52dfae5c ("tipc: obtain node identity from interface by default")

[Jon Maloy]

This one identifies the same culprit as syzbot+9d4c12...@syzkaller.appspotmail.com, but points to a different bug.
That bug has also been fixed, in commit adba75be0d23 ("tipc: fix lockdep warning when reinitilaizing sockets"), applied in 4.20 but not present in 4.16, - the source of the dump.
Once again, a dump from 4.20/5.0 might be a help.

///jon

[Dmitry Vyukov]

On Wed, Mar 20, 2019 at 4:59 PM Jon Maloy <jon....@ericsson.com> wrote:
>
> This one identifies the same culprit as syzbot+9d4c12...@syzkaller.appspotmail.com, but points to a different bug.
> That bug has also been fixed, in commit adba75be0d23 ("tipc: fix lockdep warning when reinitilaizing sockets"), applied in 4.20 but not present in 4.16, - the source of the dump.
> Once again, a dump from 4.20/5.0 might be a help.

Looking at the bisection log maybe this reproducer triggers multiple
kernel bugs.
All crashes including the latest ones and other info are always
available on the dashboard.

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/BL0PR1501MB20039998B662DCC11E2B38D79A410%40BL0PR1501MB2003.namprd15.prod.outlook.com.
> For more options, visit https://groups.google.com/d/optout.

[Jon Maloy]

> -----Original Message-----
> From: Dmitry Vyukov <dvy...@google.com>
> Sent: 20-Mar-19 17:41
> To: Jon Maloy <jon....@ericsson.com>
> Cc: syzbot <syzbot+a25307...@syzkaller.appspotmail.com>;
> da...@davemloft.net; kuz...@ms2.inr.ac.ru; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; syzkaller-
> bu...@googlegroups.com; tipc-di...@lists.sourceforge.net;
> ying...@windriver.com; yosh...@linux-ipv6.org
> Subject: Re: general protection fault in fib6_purge_rt
>

> On Wed, Mar 20, 2019 at 4:59 PM Jon Maloy <jon....@ericsson.com>
> wrote:
> >
> > This one identifies the same culprit as
> syzbot+9d4c12...@syzkaller.appspotmail.com, but points to a
> different bug.
> > That bug has also been fixed, in commit adba75be0d23 ("tipc: fix lockdep
> warning when reinitilaizing sockets"), applied in 4.20 but not present in 4.16, -
> the source of the dump.
> > Once again, a dump from 4.20/5.0 might be a help.
>
>
> Looking at the bisection log maybe this reproducer triggers multiple kernel
> bugs.

I think so.

> All crashes including the latest ones and other info are always available on
> the dashboard.

Looking at the latest dashboard reports, I don't see anything that points to TIPC.

///jon

[Xin Long]

On Thu, Mar 21, 2019 at 12:54 AM Jon Maloy <jon....@ericsson.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dmitry Vyukov <dvy...@google.com>
> > Sent: 20-Mar-19 17:41
> > To: Jon Maloy <jon....@ericsson.com>
> > Cc: syzbot <syzbot+a25307...@syzkaller.appspotmail.com>;
> > da...@davemloft.net; kuz...@ms2.inr.ac.ru; linux-
> > ker...@vger.kernel.org; net...@vger.kernel.org; syzkaller-
> > bu...@googlegroups.com; tipc-di...@lists.sourceforge.net;
> > ying...@windriver.com; yosh...@linux-ipv6.org
> > Subject: Re: general protection fault in fib6_purge_rt
> >
> > On Wed, Mar 20, 2019 at 4:59 PM Jon Maloy <jon....@ericsson.com>
> > wrote:
> > >
> > > This one identifies the same culprit as
> > syzbot+9d4c12...@syzkaller.appspotmail.com, but points to a
> > different bug.
> > > That bug has also been fixed, in commit adba75be0d23 ("tipc: fix lockdep
> > warning when reinitilaizing sockets"), applied in 4.20 but not present in 4.16, -
> > the source of the dump.
> > > Once again, a dump from 4.20/5.0 might be a help.

Hi, Jon,

I was running the reproducer against the net.git kernel which includes
commit adba75be0d23.

Another panic showed up:

[ 156.086487] ==================================================================
[ 156.088228] BUG: KASAN: use-after-free in
tipc_disc_timeout+0x9c9/0xb20 [tipc]
[ 156.089740] Read of size 8 at addr ffff88802fdb1be8 by task swapper/1/0
[ 156.091120]
[ 156.091471] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.0.0.test.syz #257
[ 156.092873] Hardware name: Red Hat KVM, BIOS seabios-1.7.5-8.el7 04/01/2014
[ 156.094315] Call Trace:
[ 156.094844] <IRQ>
[ 156.095306] dump_stack+0x7c/0xc0
[ 156.096040] ? tipc_disc_timeout+0x9c9/0xb20 [tipc]
[ 156.097346] print_address_description+0x65/0x22e
[ 156.098360] ? tipc_disc_timeout+0x9c9/0xb20 [tipc]
[ 156.099408] ? tipc_disc_timeout+0x9c9/0xb20 [tipc]
[ 156.100445] kasan_report.cold.3+0x37/0x7a
[ 156.101348] ? tipc_disc_timeout+0x9c9/0xb20 [tipc]
[ 156.102402] tipc_disc_timeout+0x9c9/0xb20 [tipc]
[ 156.103641] ? tipc_disc_msg_xmit.isra.19+0x180/0x180 [tipc]
[ 156.104830] ? __lock_is_held+0xb4/0x140
[ 156.105669] ? call_timer_fn+0xd1/0x610
[ 156.106517] call_timer_fn+0x19a/0x610
[ 156.107342] ? tipc_disc_msg_xmit.isra.19+0x180/0x180 [tipc]
[ 156.108538] ? timer_fixup_init+0x30/0x30
[ 156.109411] ? _raw_spin_unlock_irq+0x29/0x40
[ 156.110343] ? tipc_disc_msg_xmit.isra.19+0x180/0x180 [tipc]
[ 156.111545] ? tipc_disc_msg_xmit.isra.19+0x180/0x180 [tipc]
[ 156.112749] run_timer_softirq+0xb51/0x1090
[ 156.113656] ? add_timer+0x8d0/0x8d0
[ 156.114433] ? kvm_sched_clock_read+0x14/0x30
[ 156.115355] ? sched_clock+0x5/0x10
[ 156.116124] __do_softirq+0x236/0xa1c
[ 156.116943] irq_exit+0x281/0x2d0
[ 156.117657] smp_apic_timer_interrupt+0x172/0x5d0
[ 156.118658] apic_timer_interrupt+0xf/0x20


I think it's caused by that d->timer wasn't deleted after the netns has been
destroyed, and tipc_disc_timeout() still used d->net that has been freed.

I looked at the __net_exit path, it should have been done by:
tipc_exit_net() ->
tipc_net_stop()->
tipc_bearer_stop()->
bearer_disable()->
tipc_disc_delete()->
del_timer_sync(&d->timer)

but because of if (!self), it returned in tipc_net_stop().

It seems to me that whether to do tipc_bearer/node_stop() for netns or not
shouldn't depend on tipc_net(net)->node_addr.
Can we just remove that if(!self) from tipc_net_stop() to fix it?
and also seems tipc_nametbl_stop() will do the clean job for nametbl,
should tipc_nametbl_withdraw() also be removed from tipc_net_stop()?

diff --git a/net/tipc/net.c b/net/tipc/net.c
index f076edb..3647984 100644
--- a/net/tipc/net.c
+++ b/net/tipc/net.c
@@ -163,12 +163,6 @@ void tipc_sched_net_finalize(struct net *net, u32 addr)

void tipc_net_stop(struct net *net)
{
- u32 self = tipc_own_addr(net);
-
- if (!self)
- return;
-
- tipc_nametbl_withdraw(net, TIPC_CFG_SRV, self, self, self);
rtnl_lock();
tipc_bearer_stop(net);
tipc_node_stop(net);

[Jon Maloy]

> > > syzbot+a

That would probably work. Previous to the problematic commit, (!self) just meant that we had never entered
network mode, and that there was nothing to stop or delete. That changed when this patch introduced
the address negotiation period. So, if somebody leaves network mode before the hash address has been set, this will happen.

My concern is that we might run into surprises when we continue into the later functions, such as tipc_bearer_stop(), so I would prefer to avoid that.
The safer approach would be to now instead test for if (!tipc_own_id(net)), which now serves as a safe indicator if we have entered network node or not.

> and also seems tipc_nametbl_stop() will do the clean job for nametbl, should
> tipc_nametbl_withdraw() also be removed from tipc_net_stop()?

Yes. This looks like legacy from the previous implementation.

///jon

[Xin Long]

But even previous to commit 52dfae5c85, if TIPC_NLA_NET_NODEID is set
by netlink, tn->node_id will be set and tn->node_addr is still NULL.
bear/nodes can be allocated in tipc_enable_bearer(), the panic would
be triggered, right?

>
> My concern is that we might run into surprises when we continue into the later functions, such as tipc_bearer_stop(), so I would prefer to avoid that.
> The safer approach would be to now instead test for if (!tipc_own_id(net)), which now serves as a safe indicator if we have entered network node or not.

okay, as long as no node/bear can be allocated when node_id is not set yet. :)

[Jon Maloy]

> > > > > syzbot+points to a

Yes. You are right.

>
> >
> > My concern is that we might run into surprises when we continue into the
> later functions, such as tipc_bearer_stop(), so I would prefer to avoid that.
> > The safer approach would be to now instead test for if
> (!tipc_own_id(net)), which now serves as a safe indicator if we have entered
> network node or not.
> okay, as long as no node/bear can be allocated when node_id is not set yet.
> :)

Yes, that is the case.
///jon