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.
>
> But generally speaking, the current logic is very fragile. It claims
> to be more reliable when the system is low on memory, but in fact, it
> consumes two times more memory as at the moment of running this
> function, there are two vports allocated with their queues and vectors.
> Moreover, it claims to prevent the driver from running into "bad state",
> but in fact, any error during the rebuild leaves the old vport in the
> partially allocated state.
> Finally, if the interface is down when the function is called, it always
> allocates a new queue set, but when the user decides to enable the
> interface later on, vport_open() allocates them once again, IOW there's
> a clear memory leak here.
>
> Just don't allocate a new queue set when performing a reset, that solves
> crashes and memory leaks. Readd the old queue number and reopen the
> interface on rollback - that solves limbo states when the device is left
> disabled and/or without HW queues enabled.
>
> Fixes: 02cbfba1add5 ("idpf: add ethtool callbacks")
> Fixes: e4891e4687c8 ("idpf: split &idpf_queue into 4 strictly-typed queue
> structures")
> Signed-off-by: Alexander Lobakin <aleksander.loba...@intel.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf_lib.c | 30 +++++++++++-----------
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c
> b/drivers/net/ethernet/intel/idpf/idpf_lib.c
...
> @@ -1932,17 +1926,23 @@ int idpf_initiate_soft_reset(struct idpf_vport *vport,
>
> err = idpf_set_real_num_queues(vport);
> if (err)
> - goto err_reset;
> + goto err_open;
>
> if (current_state == __IDPF_VPORT_UP)
> - err = idpf_vport_open(vport, false);
> + err = idpf_vport_open(vport);
>
> kfree(new_vport);
>
> return err;
>
> 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.
> +
> free_vport:
> kfree(new_vport);
>
...
