[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230527100544.cf4nyq33e24atmv4@fpc>
Date: Sat, 27 May 2023 13:05:44 +0300
From: Fedor Pchelkin <pchelkin@...ras.ru>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>, kernel@...gutronix.de,
Robin van der Gracht <robin@...tonic.nl>,
Oliver Hartkopp <socketcan@...tkopp.net>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Kurt Van Dijck <dev.kurt@...dijck-laurijssen.be>,
linux-can@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
Alexey Khoroshilov <khoroshilov@...ras.ru>,
lvc-project@...uxtesting.org
Subject: Re: [PATCH 2/2] can: j1939: avoid possible use-after-free when
j1939_can_rx_register fails
On Sat, May 27, 2023 at 07:57:04AM +0200, Oleksij Rempel wrote:
> Hi Fedor,
>
> On Fri, May 26, 2023 at 09:50:26PM +0300, Fedor Pchelkin wrote:
> > Hi Oleksij,
> >
> > thanks for the reply!
> >
> > On Fri, May 26, 2023 at 08:15:00PM +0200, Oleksij Rempel wrote:
> > > Hi Fedor,
> > >
> > > On Fri, May 26, 2023 at 08:19:10PM +0300, Fedor Pchelkin wrote:
> > >
> > >
> > > Thank you for your investigation. How about this change?
> > > --- a/net/can/j1939/main.c
> > > +++ b/net/can/j1939/main.c
> > > @@ -285,8 +285,7 @@ struct j1939_priv *j1939_netdev_start(struct net_device *ndev)
> > > */
> > > kref_get(&priv_new->rx_kref);
> > > spin_unlock(&j1939_netdev_lock);
> > > - dev_put(ndev);
> > > - kfree(priv);
> > > + j1939_priv_put(priv);
> >
> > I don't think that's good because the priv which is directly freed here is
> > still local to the thread, and parallel threads don't have any access to
> > it. j1939_priv_create() has allocated a fresh priv and called dev_hold()
> > so dev_put() and kfree() here are okay.
> >
> > > return priv_new;
> > > }
> > > j1939_priv_set(ndev, priv);
> > > @@ -300,8 +299,7 @@ struct j1939_priv *j1939_netdev_start(struct net_device *ndev)
> > >
> > > out_priv_put:
> > > j1939_priv_set(ndev, NULL);
> > > - dev_put(ndev);
> > > - kfree(priv);
> > > + j1939_priv_put(priv);
> > >
> > > return ERR_PTR(ret);
> > > }
> > >
> > > If I see it correctly, the problem is kfree() which is called without respecting
> > > the ref counting. If CPU1 has priv_new, refcounting is increased. The priv will
> > > not be freed on this place.
> >
> > With your suggestion, I think it doesn't work correctly if
> > j1939_can_rx_register() fails and we go to out_priv_put. The priv is kept
> > but the parallel thread which may have already grabbed it thinks that
> > j1939_can_rx_register() has succeeded when actually it hasn't succeed.
> > Moreover, j1939_priv_set() makes it NULL on error path so that priv cannot
> > be accessed from ndev.
> >
> > I also considered the alternatives where we don't have to serialize access
> > to j1939_can_rx_register() and subsequently introduce mutex. But with
> > current j1939_netdev_start() implementation I can't see how to fix the
> > racy bug without it.
>
> Ok, it make sense.
>
> I'll try to do some testing next week. If i'll forget it, please feel
> free to ping me.
Got it, thank you.
>
> Regards,
> Oleksij
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Powered by blists - more mailing lists