[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MW4PR11MB59117778576257F433152BE3BAB32@MW4PR11MB5911.namprd11.prod.outlook.com>
Date: Fri, 2 Aug 2024 00:21:33 +0000
From: "Singh, Krishneil K" <krishneil.k.singh@...el.com>
To: Simon Horman <horms@...nel.org>, "Lobakin, Aleksander"
<aleksander.lobakin@...el.com>
CC: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, "NEX SW NCIS OSDT ITP
Upstreaming" <nex.sw.ncis.osdt.itp.upstreaming@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH iwl-net 1/3] idpf: fix memory leaks and crashes while
performing a soft reset
> -----Original Message-----
> From: Simon Horman <horms@...nel.org>
> Sent: Tuesday, July 30, 2024 9:37 AM
> To: Lobakin, Aleksander <aleksander.lobakin@...el.com>
> Cc: intel-wired-lan@...ts.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; David S. Miller <davem@...emloft.net>; Eric
> Dumazet <edumazet@...gle.com>; Jakub Kicinski <kuba@...nel.org>; Paolo
> Abeni <pabeni@...hat.com>; NEX SW NCIS OSDT ITP Upstreaming
> <nex.sw.ncis.osdt.itp.upstreaming@...el.com>; netdev@...r.kernel.org; linux-
> kernel@...r.kernel.org
> Subject: Re: [PATCH iwl-net 1/3] idpf: fix memory leaks and crashes while
> performing a soft reset
>
> On Mon, Jul 29, 2024 at 10:54:50AM +0200, Alexander Lobakin wrote:
> > From: Simon Horman <horms@...nel.org>
> > Date: Fri, 26 Jul 2024 17:09:54 +0100
> >
> > > On Wed, Jul 24, 2024 at 03:40:22PM +0200, Alexander Lobakin wrote:
> > >> The second tagged commit introduced a UAF, as it removed restoring
> > >> q_vector->vport pointers after reinitializating the structures.
> > >> This is due to that all queue allocation functions are performed here
> > >> with the new temporary vport structure and those functions rewrite
> > >> the backpointers to the vport. Then, this new struct is freed and
> > >> the pointers start leading to nowhere.
> >
> > [...]
> >
> > >> err_reset:
> > >> - idpf_vport_queues_rel(new_vport);
> > >> + idpf_send_add_queues_msg(vport, vport->num_txq, vport-
> >num_complq,
> > >> + vport->num_rxq, vport->num_bufq);
> > >> +
> > >> +err_open:
> > >> + if (current_state == __IDPF_VPORT_UP)
> > >> + idpf_vport_open(vport);
> > >
> > > Hi Alexander,
> > >
> > > Can the system end up in an odd state if this call to idpf_vport_open(), or
> > > the one above, fails. Likewise if the above call to
> > > idpf_send_add_queues_msg() fails.
> >
> > Adding the queues with the parameters that were before changing them
> > almost can't fail. But if any of these two fails, it really will be in
> > an odd state...
>
> Thanks for the clarification, this is my concern.
>
> > Perhaps we need to do a more powerful reset then? Can we somehow tell
> > the kernel that in fact our iface is down, so that the user could try
> > to enable it manually once again?
> > Anyway, feels like a separate series or patch to -next, what do you think?
>
> Yes, sure. I agree that this patch improves things, and more extreme
> corner cases can be addressed separately.
>
> With the above in mind, I'm happy with this patch.
>
> Reviewed-by: Simon Horman <horms@...nel.org>
>
Tested-by: Krishneil Singh <krishneil.k.singh@...el.com>
Powered by blists - more mailing lists