netdev - Re: [PATCH net-next v5 4/4] virtio-net: support rx netdim

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: <4608e204307b1fb16e1f98e0a9c52e6ce2d0a3db.camel@redhat.com>
Date: Thu, 30 Nov 2023 13:23:51 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Heng Qi <hengqi@...ux.alibaba.com>, 
	virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org
Cc: jasowang@...hat.com, mst@...hat.com, kuba@...nel.org,
 edumazet@...gle.com,  davem@...emloft.net, hawk@...nel.org,
 john.fastabend@...il.com, ast@...nel.org,  horms@...nel.org,
 xuanzhuo@...ux.alibaba.com, yinjun.zhang@...igine.com
Subject: Re: [PATCH net-next v5 4/4] virtio-net: support rx netdim

On Thu, 2023-11-30 at 20:09 +0800, Heng Qi wrote:
> 
> 在 2023/11/30 下午5:33, Paolo Abeni 写道:
> > On Mon, 2023-11-27 at 10:55 +0800, Heng Qi wrote:
> > > @@ -4738,11 +4881,14 @@ static void remove_vq_common(struct virtnet_info *vi)
> > >   static void virtnet_remove(struct virtio_device *vdev)
> > >   {
> > >   	struct virtnet_info *vi = vdev->priv;
> > > +	int i;
> > >   
> > >   	virtnet_cpu_notif_remove(vi);
> > >   
> > >   	/* Make sure no work handler is accessing the device. */
> > >   	flush_work(&vi->config_work);
> > > +	for (i = 0; i < vi->max_queue_pairs; i++)
> > > +		cancel_work(&vi->rq[i].dim.work);
> > If the dim work is still running here, what prevents it from completing
> > after the following unregister/free netdev?
> 
> Yes, no one here is trying to stop it, 

So it will cause UaF, right?

> the situation is like 
> unregister/free netdev
> when rss are being set, so I think this is ok.
 
Could you please elaborate more the point?

> > It looks like you want need to call cancel_work_sync here?
> 
> In v4, Yinjun Zhang mentioned that _sync() can cause deadlock[1].
> Therefore, cancel_work() is used here instead of cancel_work_sync() to 
> avoid possible deadlock.
> 
> [1] 
> https://lore.kernel.org/all/20231122092939.1005591-1-yinjun.zhang@corigine.com/

Here the call to cancel_work() happens while the caller does not held
the rtnl lock, the deadlock reported above will not be triggered.

> > Additionally the later remove_vq_common() will needless call
> > cancel_work() again;
> 
> Yes. remove_vq_common() now does not call cancel_work().

I'm sorry, I missread the context in a previous chunk.

The other point should still apply.

Cheers,

Paolo