[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20200507.181930.292334116869510588.davem@davemloft.net>
Date: Thu, 07 May 2020 18:19:30 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: xiyou.wangcong@...il.com
Cc: netdev@...r.kernel.org,
syzbot+e73ceacfd8560cc8a3ca@...kaller.appspotmail.com,
syzbot+c2fb6f9ddcea95ba49b5@...kaller.appspotmail.com,
jarod@...hat.com, nikolay@...ulusnetworks.com, jpoimboe@...hat.com,
jannh@...gle.com, jay.vosburgh@...onical.com
Subject: Re: [Patch net v3] net: fix a potential recursive
NETDEV_FEAT_CHANGE
From: Cong Wang <xiyou.wangcong@...il.com>
Date: Thu, 7 May 2020 12:19:03 -0700
> syzbot managed to trigger a recursive NETDEV_FEAT_CHANGE event
> between bonding master and slave. I managed to find a reproducer
> for this:
>
> ip li set bond0 up
> ifenslave bond0 eth0
> brctl addbr br0
> ethtool -K eth0 lro off
> brctl addif br0 bond0
> ip li set br0 up
>
> When a NETDEV_FEAT_CHANGE event is triggered on a bonding slave,
> it captures this and calls bond_compute_features() to fixup its
> master's and other slaves' features. However, when syncing with
> its lower devices by netdev_sync_lower_features() this event is
> triggered again on slaves when the LRO feature fails to change,
> so it goes back and forth recursively until the kernel stack is
> exhausted.
>
> Commit 17b85d29e82c intentionally lets __netdev_update_features()
> return -1 for such a failure case, so we have to just rely on
> the existing check inside netdev_sync_lower_features() and skip
> NETDEV_FEAT_CHANGE event only for this specific failure case.
>
> Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack")
> Reported-by: syzbot+e73ceacfd8560cc8a3ca@...kaller.appspotmail.com
> Reported-by: syzbot+c2fb6f9ddcea95ba49b5@...kaller.appspotmail.com
> Cc: Jarod Wilson <jarod@...hat.com>
> Cc: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
> Cc: Josh Poimboeuf <jpoimboe@...hat.com>
> Cc: Jann Horn <jannh@...gle.com>
> Reviewed-by: Jay Vosburgh <jay.vosburgh@...onical.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@...il.com>
Applied and queued up for -stable, thanks Cong.
Powered by blists - more mailing lists