netdev - Re: [syzbot] [net?] possible deadlock in team_del

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]

Message-Id: <20240705151719.94431-1-aha310510@gmail.com>
Date: Sat,  6 Jul 2024 00:17:19 +0900
From: Jeongjun Park <aha310510@...il.com>
To: edumazet@...gle.com
Cc: aha310510@...il.com,
	davem@...emloft.net,
	jiri@...nulli.us,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	michal.kubiak@...el.com,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	syzbot+705c61d60b091ef42c04@...kaller.appspotmail.com,
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [net?] possible deadlock in team_del_slave (3)

> >
> > Thanks for your comment. I rewrote the patch based on those comments.
> > This time, we modified it to return an error so that resources are not
> > modified when a race situation occurs. We would appreciate your
> > feedback on what this patch would be like.
> >
> > > Thanks,
> > > Michal
> > >
> > >
> >
> > Regards,
> > Jeongjun Park
> >
> > ---
> >  drivers/net/team/team_core.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
> > index ab1935a4aa2c..43d7c73b25aa 100644
> > --- a/drivers/net/team/team_core.c
> > +++ b/drivers/net/team/team_core.c
> > @@ -1972,7 +1972,8 @@ static int team_add_slave(struct net_device *dev, struct net_device *port_dev,
> >         struct team *team = netdev_priv(dev);
> >         int err;
> >
> > -       mutex_lock(&team->lock);
> > +       if (!mutex_trylock(&team->lock))
> > +               return -EBUSY;
> >         err = team_port_add(team, port_dev, extack);
> >         mutex_unlock(&team->lock);
> >
> > @@ -1987,7 +1988,8 @@ static int team_del_slave(struct net_device *dev, struct net_device *port_dev)
> >         struct team *team = netdev_priv(dev);
> >         int err;
> >
> > -       mutex_lock(&team->lock);
> > +       if (!mutex_trylock(&team->lock))
> > +               return -EBUSY;
> >         err = team_port_del(team, port_dev);
> >         mutex_unlock(&team->lock);
> >
> > --
>
> Failing team_del_slave() is not an option. It will add various issues.

Thank you for comment. 

So, how about briefly releasing the lock before calling dev_open()
in team_port_add() and then locking it again? dev_open() does not use
&team, so disabling it briefly will not cause any major problems.

Regards,
Jeongjun Park

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

diff --git a/drivers/net/team/team_core.c b/drivers/net/team/team_core.c
index ab1935a4aa2c..245566a1875d 100644
--- a/drivers/net/team/team_core.c
+++ b/drivers/net/team/team_core.c
@@ -1213,7 +1213,9 @@ static int team_port_add(struct team *team, struct net_device *port_dev,
 		goto err_port_enter;
 	}
 
+	mutex_unlock(&team->lock);
 	err = dev_open(port_dev, extack);
+	mutex_lock(&team->lock);
 	if (err) {
 		netdev_dbg(dev, "Device %s opening failed\n",
 			   portname);
--