> +
> > + if (*max_sq == 0 || *max_rq == 0) {
> > + netdev_err(apc->ndev, "Invalid max queues from vPort config\n");
> > + return -EPROTO;
>
> AI review says:
>
> Will returning -EPROTO here expose a pre-existing resource leak in the
> driver's teardown path?
> If mana_query_vport_cfg() returns an error, mana_init_port() fails and
> mana_probe_port() frees the ndev, leaving ac->ports[i] as NULL. In
> mana_probe(), the port initialization loop breaks upon this error, but
> the err variable is then overwritten:
>
> mana_probe() {
> ...
> for (i = 0; i < ac->num_ports; i++) {
> err = mana_probe_port(ac, i, &ac->ports[i]);
> if (err) {
> dev_err(dev, "Probe Failed for port %d\n", i);
> break;
> }
> }
>
> err = add_adev(gd, "eth");
> ...
> }
>
> If add_adev() succeeds, mana_probe() completes successfully instead of
> failing, masking the earlier error while leaving ac->ports[0] as NULL.
> Later, when the driver is unloaded or if add_adev() fails and triggers
> immediate cleanup, mana_remove() is called. It iterates over ac->ports
> and, upon encountering the NULL device, immediately executes goto out:
>
> mana_remove() {
> ...
> for (i = 0; i < ac->num_ports; i++) {
> ndev = ac->ports[i];
> if (!ndev) {
> if (i == 0)
> ...
> goto out;
> }
> ...
> }
>
> mana_destroy_eq(ac);
> out:
> ...
> }
>
> Because the out label in mana_remove() is located after the
> mana_destroy_eq(ac) call, jumping there completely skips destroying the
> event queues allocated earlier by mana_create_eq(ac).
> In a Confidential Virtual Machine context, could an untrusted hypervisor
> repeatedly return invalid configs to continuously leak guest memory and
> hardware queues?
Thankyou for the review.
Since these issues are pre-existing, I will send it in a separate
patchset.
The patchset will also include the issues reported in:
[PATCH net-next] net: mana: hardening: Validate adapter_mtu from
MANA_QUERY_DEV_CONFIG
- Vennela
