netdev - Re: [PATCH net-next v20 00/12] virtio_net: Add ethtool flow rules support

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: <3512ccd8-650f-4c05-b2dc-1c4588b39c87@nvidia.com>
Date: Sun, 8 Feb 2026 07:57:33 -0600
From: Dan Jurgens <danielj@...dia.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: netdev@...r.kernel.org, jasowang@...hat.com, pabeni@...hat.com,
 virtualization@...ts.linux.dev, parav@...dia.com, shshitrit@...dia.com,
 yohadt@...dia.com, xuanzhuo@...ux.alibaba.com, eperezma@...hat.com,
 jgg@...pe.ca, kevin.tian@...el.com, kuba@...nel.org, andrew+netdev@...n.ch,
 edumazet@...gle.com
Subject: Re: [PATCH net-next v20 00/12] virtio_net: Add ethtool flow rules
 support

On 2/8/26 5:55 AM, Michael S. Tsirkin wrote:
> On Thu, Feb 05, 2026 at 04:46:55PM -0600, Daniel Jurgens wrote:
>> v15:
>>   - In virtnet_restore_up only call virtnet_close in err path if
>>     netif_running. AI
> 
> what was this AI specifically?
> 

It was the AI review bot, forwarded by Jakub on v16:

> +              * remove_vq_common resets the device and frees the vqs.
> +              */
> +             vi->rx_mode_work_enabled = false;
> +             rtnl_unlock();
> +             remove_vq_common(vi);
> +             return err;

If virtnet_ff_init() fails here, remove_vq_common() frees vi->rq, vi->sq,
and vi->ctrl via virtnet_free_queues(), but the netdevice remains
registered. Could this leave the device in an inconsistent state where
subsequent operations (like virtnet_open() triggered by bringing the
interface up) would access freed memory through vi->rq[i]?

The error return propagates up to virtnet_restore() which just returns
the error without further cleanup. If userspace then tries to use the
still-registered netdevice, virtnet_open() would call try_fill_recv()
which dereferences vi->rq.

> +     }
> +     rtnl_unlock();
> +
>        netif_tx_lock_bh(vi->dev);
>        netif_device_attach(vi->dev);
>        netif_tx_unlock_bh(vi->dev);
> -     return err;
> +     return 0;
>  }
--
pw-bot: cr