netdev - Re: [PATCH net] bonding: stop the device in bond_setup_by

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 11 Nov 2023 14:28:40 +0800
From: Hangbin Liu <liuhangbin@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Jay Vosburgh <j.vosburgh@...il.com>,
	Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org,
	eric.dumazet@...il.com, syzbot <syzkaller@...glegroups.com>
Subject: Re: [PATCH net] bonding: stop the device in bond_setup_by_slave()

On Fri, Nov 10, 2023 at 09:38:18AM +0100, Eric Dumazet wrote:
> On Fri, Nov 10, 2023 at 4:44 AM Hangbin Liu <liuhangbin@...il.com> wrote:
> >
> > On Thu, Nov 09, 2023 at 06:01:02PM +0000, Eric Dumazet wrote:
> > > Commit 9eed321cde22 ("net: lapbether: only support ethernet devices")
> > > has been able to keep syzbot away from net/lapb, until today.
> > >
> > > In the following splat [1], the issue is that a lapbether device has
> > > been created on a bonding device without members. Then adding a non
> > > ARPHRD_ETHER member forced the bonding master to change its type.
> > >
> > > The fix is to make sure we call dev_close() in bond_setup_by_slave()
> > > so that the potential linked lapbether devices (or any other devices
> > > having assumptions on the physical device) are removed.
> > >
> > > A similar bug has been addressed in commit 40baec225765
> > > ("bonding: fix panic on non-ARPHRD_ETHER enslave failure")
> > >
> >
> > Do we need also do this if the bond changed to ether device from other dev
> > type? e.g.
> >
> >     if (slave_dev->type != ARPHRD_ETHER)
> >             bond_setup_by_slave(bond_dev, slave_dev);
> >     else
> >             bond_ether_setup(bond_dev);
> 
> Hmmm... possibly, but as far as I know, nothing can be stacked on top of IPoIB

The "stacked on top of IPoIB", do you mean IPoIB as an up layer or down layer
device?

BTW, not only IPoIB can be enslaved to bond, but also other types like gre could be
enslaved to bond.

Thanks
Hangbin