[syzbot] [net?] BUG: sleeping function called from invalid context in team_change_rx_flags (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: dd831ac8221e net/sched: sch_qfq: Fix null-deref in agg_deq..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=13245bd4580000
kernel config: https://syzkaller.appspot.com/x/.config?x=b29b1a0d7330d4a8
dashboard link: https://syzkaller.appspot.com/bug?extid=8182574047912f805d59
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b7b63815bf2a/disk-dd831ac8.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f857222aabbb/vmlinux-dd831ac8.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9071ec6016d0/bzImage-dd831ac8.xz

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

netlink: 8 bytes leftover after parsing attributes in process `syz.1.1814'.
macsec0: entered promiscuous mode
team0: entered promiscuous mode
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:579
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 12326, name: syz.1.1814
preempt_count: 201, expected: 0
RCU nest depth: 0, expected: 0
3 locks held by syz.1.1814/12326:
#0: ffffffff8fa21eb8 (&ops->srcu#2){.+.+}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
#0: ffffffff8fa21eb8 (&ops->srcu#2){.+.+}-{0:0}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
#0: ffffffff8fa21eb8 (&ops->srcu#2){.+.+}-{0:0}, at: rtnl_link_ops_get+0x23/0x250 net/core/rtnetlink.c:570
#1: ffffffff8f51c5c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
#1: ffffffff8f51c5c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock net/core/rtnetlink.c:341 [inline]
#1: ffffffff8f51c5c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x8db/0x1c70 net/core/rtnetlink.c:4054
#2: ffff8880635e8368 (&macsec_netdev_addr_lock_key#2/2){+...}-{3:3}, at: netif_addr_lock_bh include/linux/netdevice.h:4805 [inline]
#2: ffff8880635e8368 (&macsec_netdev_addr_lock_key#2/2){+...}-{3:3}, at: dev_uc_add+0x67/0x120 net/core/dev_addr_lists.c:689
Preemption disabled at:
[<ffffffff895a7d26>] local_bh_disable include/linux/bottom_half.h:20 [inline]
[<ffffffff895a7d26>] netif_addr_lock_bh include/linux/netdevice.h:4804 [inline]
[<ffffffff895a7d26>] dev_uc_add+0x56/0x120 net/core/dev_addr_lists.c:689
CPU: 0 UID: 0 PID: 12326 Comm: syz.1.1814 Not tainted 6.16.0-rc4-syzkaller-00153-gdd831ac8221e #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
__might_resched+0x495/0x610 kernel/sched/core.c:8800
__mutex_lock_common kernel/locking/mutex.c:579 [inline]
__mutex_lock+0x106/0xe80 kernel/locking/mutex.c:747
team_change_rx_flags+0x38/0x220 drivers/net/team/team_core.c:1781
dev_change_rx_flags net/core/dev.c:9241 [inline]
__dev_set_promiscuity+0x534/0x740 net/core/dev.c:9285
netif_set_promiscuity+0x50/0xe0 net/core/dev.c:9305
dev_set_promiscuity+0x126/0x260 net/core/dev_api.c:287
dev_change_rx_flags net/core/dev.c:9241 [inline]
__dev_set_promiscuity+0x534/0x740 net/core/dev.c:9285
__dev_set_rx_mode+0x17c/0x260 net/core/dev.c:-1
dev_uc_add+0xc8/0x120 net/core/dev_addr_lists.c:693
macsec_dev_open+0xd9/0x530 drivers/net/macsec.c:3634
__dev_open+0x470/0x880 net/core/dev.c:1683
__dev_change_flags+0x1ea/0x6d0 net/core/dev.c:9458
rtnl_configure_link net/core/rtnetlink.c:3577 [inline]
rtnl_newlink_create+0x555/0xb00 net/core/rtnetlink.c:3833
__rtnl_newlink net/core/rtnetlink.c:3940 [inline]
rtnl_newlink+0x16d6/0x1c70 net/core/rtnetlink.c:4055
rtnetlink_rcv_msg+0x7cc/0xb70 net/core/rtnetlink.c:6944
netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2551
netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
netlink_unicast+0x75c/0x8e0 net/netlink/af_netlink.c:1346
netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg+0x219/0x270 net/socket.c:727
____sys_sendmsg+0x505/0x830 net/socket.c:2566
___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620
__sys_sendmsg net/socket.c:2652 [inline]
__do_sys_sendmsg net/socket.c:2657 [inline]
__se_sys_sendmsg net/socket.c:2655 [inline]
__x64_sys_sendmsg+0x19b/0x260 net/socket.c:2655
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2785b8e929
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f27869d6038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f2785db5fa0 RCX: 00007f2785b8e929
RDX: 0000000000000800 RSI: 0000200000000280 RDI: 0000000000000009
RBP: 00007f2785c10b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f2785db5fa0 R15: 00007ffe1c84aa28
</TASK>

=============================
[ BUG: Invalid wait context ]
6.16.0-rc4-syzkaller-00153-gdd831ac8221e #0 Tainted: G W
-----------------------------
syz.1.1814/12326 is trying to lock:
ffff88802715ce00 (team->team_lock_key#2){+.+.}-{4:4}, at: team_change_rx_flags+0x38/0x220 drivers/net/team/team_core.c:1781
other info that might help us debug this:
context-{5:5}
3 locks held by syz.1.1814/12326:
#0: ffffffff8fa21eb8 (&ops->srcu#2){.+.+}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
#0: ffffffff8fa21eb8 (&ops->srcu#2){.+.+}-{0:0}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
#0: ffffffff8fa21eb8 (&ops->srcu#2){.+.+}-{0:0}, at: rtnl_link_ops_get+0x23/0x250 net/core/rtnetlink.c:570
#1: ffffffff8f51c5c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
#1: ffffffff8f51c5c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock net/core/rtnetlink.c:341 [inline]
#1: ffffffff8f51c5c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x8db/0x1c70 net/core/rtnetlink.c:4054
#2: ffff8880635e8368 (&macsec_netdev_addr_lock_key#2/2){+...}-{3:3}, at: netif_addr_lock_bh include/linux/netdevice.h:4805 [inline]
#2: ffff8880635e8368 (&macsec_netdev_addr_lock_key#2/2){+...}-{3:3}, at: dev_uc_add+0x67/0x120 net/core/dev_addr_lists.c:689
stack backtrace:
CPU: 0 UID: 0 PID: 12326 Comm: syz.1.1814 Tainted: G W 6.16.0-rc4-syzkaller-00153-gdd831ac8221e #0 PREEMPT(full)
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_lock_invalid_wait_context kernel/locking/lockdep.c:4833 [inline]
check_wait_context kernel/locking/lockdep.c:4905 [inline]
__lock_acquire+0xbcb/0xd20 kernel/locking/lockdep.c:5190
lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
__mutex_lock_common kernel/locking/mutex.c:602 [inline]
__mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
team_change_rx_flags+0x38/0x220 drivers/net/team/team_core.c:1781
dev_change_rx_flags net/core/dev.c:9241 [inline]
__dev_set_promiscuity+0x534/0x740 net/core/dev.c:9285
netif_set_promiscuity+0x50/0xe0 net/core/dev.c:9305
dev_set_promiscuity+0x126/0x260 net/core/dev_api.c:287
dev_change_rx_flags net/core/dev.c:9241 [inline]
__dev_set_promiscuity+0x534/0x740 net/core/dev.c:9285
__dev_set_rx_mode+0x17c/0x260 net/core/dev.c:-1
dev_uc_add+0xc8/0x120 net/core/dev_addr_lists.c:693
macsec_dev_open+0xd9/0x530 drivers/net/macsec.c:3634
__dev_open+0x470/0x880 net/core/dev.c:1683
__dev_change_flags+0x1ea/0x6d0 net/core/dev.c:9458
rtnl_configure_link net/core/rtnetlink.c:3577 [inline]
rtnl_newlink_create+0x555/0xb00 net/core/rtnetlink.c:3833
__rtnl_newlink net/core/rtnetlink.c:3940 [inline]
rtnl_newlink+0x16d6/0x1c70 net/core/rtnetlink.c:4055
rtnetlink_rcv_msg+0x7cc/0xb70 net/core/rtnetlink.c:6944
netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2551
netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
netlink_unicast+0x75c/0x8e0 net/netlink/af_netlink.c:1346
netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg+0x219/0x270 net/socket.c:727
____sys_sendmsg+0x505/0x830 net/socket.c:2566
___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620
__sys_sendmsg net/socket.c:2652 [inline]
__do_sys_sendmsg net/socket.c:2657 [inline]
__se_sys_sendmsg net/socket.c:2655 [inline]
__x64_sys_sendmsg+0x19b/0x260 net/socket.c:2655
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2785b8e929
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f27869d6038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f2785db5fa0 RCX: 00007f2785b8e929
RDX: 0000000000000800 RSI: 0000200000000280 RDI: 0000000000000009
RBP: 00007f2785c10b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f2785db5fa0 R15: 00007ffe1c84aa28
</TASK>


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

[Andrew Lunn]

> drivers/net/team/team_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
> index 8bc56186b2a3..4568075fea6e 100644
> --- a/drivers/net/team/team_core.c
> +++ b/drivers/net/team/team_core.c
> @@ -1778,7 +1778,7 @@ static void team_change_rx_flags(struct net_device *dev, int change)
> struct team_port *port;
> int inc;
>
> - mutex_lock(&team->lock);
> + spin_lock(&team->lock);
> list_for_each_entry(port, &team->port_list, list) {
> if (change & IFF_PROMISC) {
> inc = dev->flags & IFF_PROMISC ? 1 : -1;
> @@ -1789,7 +1789,7 @@ static void team_change_rx_flags(struct net_device *dev, int change)
> dev_set_allmulti(port->dev, inc);
> }
> }
> - mutex_unlock(&team->lock);
> + spin_unlock(&team->lock);
> }

void __sched mutex_unlock(struct mutex *lock)
static __always_inline void spin_unlock(spinlock_t *lock)

They take different parameters. So you need to also change the struct
team to change lock from mutex to a spinlock. And what about all the
other users of team->lock?

Did not compile this change? I doubt you did, or you would of get
warnings, maybe errors.

Andrew

[Ujwal Kundur]

> Did not compile this change? I doubt you did, or you would of get warnings, maybe errors.

Ah sorry, I shouldn't have relied on static analysis -- clangd did not
complain so I did not wait for the compilation to succeed.

> And what about all the other users of team->lock?

I see the mutex is defined in `struct team` and cannot be changed as
I've proposed here. Would switching to a spinlock across the board
degrade performance?
From what I understand, the NDO for ndo_change_rx_flags doesn't seem
to disable BHs unlike ndo_set_rx_mode [1][2] so this seems to occur
only when a new unicast address is being added via dev_uc_add [3]
(which does disable BHs).
Comparing other operations that use mutex_lock / mutex_unlock, looks
like a few of them do not have RCU protection for their NDOs requiring
lock / unlock pairs in the code, but none of them disable BHs (AFAICT)
apart from the operations dealing with unicast / multicast addressing.
If this is indeed the case, perhaps we can use a dedicated spinlock
for team_change_rx_flags? Or switch back to rcu_read_lock as I believe
it's being used in team_set_rx_mode [4] for precisely this reason. To
be honest, I do not understand the intent behind this change as
mentioned in 6b1d3c5f675cc794a015138b115afff172fb4c58.

P.S: I'm still trying to get my head around the net subsystem, so
please let me know if I've misunderstood the whole thing.

[1] https://www.kernel.org/doc/html/v6.3/networking/netdevices.html
[2] https://elixir.bootlin.com/linux/v6.16-rc7/source/net/core/dev.c#L9382
[3] https://elixir.bootlin.com/linux/v6.16-rc7/source/net/core/dev_addr_lists.c#L677
[4] https://elixir.bootlin.com/linux/v6.16-rc7/source/drivers/net/team/team_core.c#L1795

Thanks,
Ujwal

[Ujwal Kundur]

Syzkaller reports the following issue:
BUG: sleeping function called from invalid context in
team_change_rx_flags

3 locks held by syz.1.1814/12326:
#0: ffffffff8fa21eb8 (&ops->srcu#2){.+.+}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
#0: ffffffff8fa21eb8 (&ops->srcu#2){.+.+}-{0:0}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
#0: ffffffff8fa21eb8 (&ops->srcu#2){.+.+}-{0:0}, at: rtnl_link_ops_get+0x23/0x250 net/core/rtnetlink.c:570
#1: ffffffff8f51c5c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
#1: ffffffff8f51c5c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock net/core/rtnetlink.c:341 [inline]
#1: ffffffff8f51c5c8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x8db/0x1c70 net/core/rtnetlink.c:4054
#2: ffff8880635e8368 (&macsec_netdev_addr_lock_key#2/2){+...}-{3:3}, at: netif_addr_lock_bh include/linux/netdevice.h:4805 [inline]
#2: ffff8880635e8368 (&macsec_netdev_addr_lock_key#2/2){+...}-{3:3}, at: dev_uc_add+0x67/0x120 net/core/dev_addr_lists.c:689
Preemption disabled at:
[<ffffffff895a7d26>] local_bh_disable include/linux/bottom_half.h:20 [inline]

^^^^

[<ffffffff895a7d26>] netif_addr_lock_bh include/linux/netdevice.h:4804 [inline]
[<ffffffff895a7d26>] dev_uc_add+0x56/0x120 net/core/dev_addr_lists.c:689

Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_lock_invalid_wait_context kernel/locking/lockdep.c:4833 [inline]
check_wait_context kernel/locking/lockdep.c:4905 [inline]
__lock_acquire+0xbcb/0xd20 kernel/locking/lockdep.c:5190
lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
__mutex_lock_common kernel/locking/mutex.c:602 [inline]
__mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
team_change_rx_flags+0x38/0x220 drivers/net/team/team_core.c:1781
dev_change_rx_flags net/core/dev.c:9241 [inline]
__dev_set_promiscuity+0x534/0x740 net/core/dev.c:9285
netif_set_promiscuity+0x50/0xe0 net/core/dev.c:9305
dev_set_promiscuity+0x126/0x260 net/core/dev_api.c:287
dev_change_rx_flags net/core/dev.c:9241 [inline]
__dev_set_promiscuity+0x534/0x740 net/core/dev.c:9285
__dev_set_rx_mode+0x17c/0x260 net/core/dev.c:-1
dev_uc_add+0xc8/0x120 net/core/dev_addr_lists.c:693
macsec_dev_open+0xd9/0x530 drivers/net/macsec.c:3634
__dev_open+0x470/0x880 net/core/dev.c:1683
__dev_change_flags+0x1ea/0x6d0 net/core/dev.c:9458
rtnl_configure_link net/core/rtnetlink.c:3577 [inline]
rtnl_newlink_create+0x555/0xb00 net/core/rtnetlink.c:3833

mutex_lock/mutex_unlock are called from team_change_rx_flags with
BH disabled (caused by netif_addr_lock_bh). Switch to spinlock instead
to avoid sleeping with BH disabled.

Reported-by: syzbot+818257...@syzkaller.appspotmail.com
Signed-off-by: Ujwal Kundur <ujwal....@gmail.com>
---

drivers/net/team/team_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
index 8bc56186b2a3..4568075fea6e 100644
--- a/drivers/net/team/team_core.c
+++ b/drivers/net/team/team_core.c
@@ -1778,7 +1778,7 @@ static void team_change_rx_flags(struct net_device *dev, int change)
struct team_port *port;
int inc;

- mutex_lock(&team->lock);
+ spin_lock(&team->lock);
list_for_each_entry(port, &team->port_list, list) {
if (change & IFF_PROMISC) {
inc = dev->flags & IFF_PROMISC ? 1 : -1;
@@ -1789,7 +1789,7 @@ static void team_change_rx_flags(struct net_device *dev, int change)
dev_set_allmulti(port->dev, inc);
}
}
- mutex_unlock(&team->lock);
+ spin_unlock(&team->lock);
}

static void team_set_rx_mode(struct net_device *dev)
--
2.30.2

[Jiri Pirko]

This is already fixed by:
bfb4fb77f9a8 ("team: replace team lock with rtnl lock")

[Andrew Lunn]

On Mon, Jul 28, 2025 at 10:55:13AM +0530, Ujwal Kundur wrote:
> > Did not compile this change? I doubt you did, or you would of get warnings, maybe errors.
>
> Ah sorry, I shouldn't have relied on static analysis -- clangd did not
> complain so I did not wait for the compilation to succeed.
>
> > And what about all the other users of team->lock?
>
> I see the mutex is defined in `struct team` and cannot be changed as
> I've proposed here. Would switching to a spinlock across the board
> degrade performance?

Sorry, team is not my area of expertise.

> >From what I understand, the NDO for ndo_change_rx_flags doesn't seem
> to disable BHs unlike ndo_set_rx_mode [1][2] so this seems to occur
> only when a new unicast address is being added via dev_uc_add [3]
> (which does disable BHs).
> Comparing other operations that use mutex_lock / mutex_unlock, looks
> like a few of them do not have RCU protection for their NDOs requiring
> lock / unlock pairs in the code, but none of them disable BHs (AFAICT)
> apart from the operations dealing with unicast / multicast addressing.
> If this is indeed the case, perhaps we can use a dedicated spinlock
> for team_change_rx_flags? Or switch back to rcu_read_lock as I believe
> it's being used in team_set_rx_mode [4] for precisely this reason. To
> be honest, I do not understand the intent behind this change as
> mentioned in 6b1d3c5f675cc794a015138b115afff172fb4c58.

I'm guessing, but is this about passing ndo_set_rx_mode from the upper
device down to the lower devices? Maybe look at how this is
implemented for other stacked devices. A VLAN interface on a base
interface for example? A bridge interface on top of an interface.

Andrew

[Hangbin Liu]

Cc Stanislav

[Hangbin Liu]

On Tue, Jul 29, 2025 at 10:01:40AM +0000, Hangbin Liu wrote:
> Cc Stanislav

Sorry, I saw Jiri said it's already fixed by

bfb4fb77f9a8 ("team: replace team lock with rtnl lock")

Please ignore my late notification.

Regards
Hangbin

[Ujwal Kundur]

> This is already fixed by:

> bfb4fb77f9a8 ("team: replace team lock with rtnl lock")

Thanks for letting me know. I now understand ASSERT_RTNL() is a viable
alternative.

> I'm guessing, but is this about passing ndo_set_rx_mode from the upper
> device down to the lower devices? Maybe look at how this is
> implemented for other stacked devices. A VLAN interface on a base
> interface for example? A bridge interface on top of an interface.

Oh this is about stacked devices, hence the references to "lower" and
"upper". Thanks, I'll read more about them.

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.