|SUCCESS| cryptodev: reset resource pointers in init error path

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/163119

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-16

git sha: patch from series.patch
Author: Daniil Iskhakov <dish at amicon.ru>
Subject: cryptodev: reset resource pointers in init error path

This patch addresses a double-free vulnerability in cryptodev_cb_init()
by setting enq_cbs to NULL after freeing it in the error path.

> diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
> index 50071935c2..5cb9c93c77 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -811,6 +811,7 @@ cryptodev_cb_init(struct rte_cryptodev *dev)
>  	if (dev->deq_cbs == NULL) {
>  		CDEV_LOG_ERR("Failed to allocate memory for deq callbacks");
>  		rte_free(dev->enq_cbs);
> +		dev->enq_cbs = NULL;
>  		return -ENOMEM;
>  	}

Does this code also need to set dev->deq_cbs to NULL for consistency?
While the current patch fixes the immediate double-free issue for
enq_cbs, should the deq_cbs pointer also be explicitly set to NULL in
case the calling code attempts cleanup based on that pointer's value?

Looking at the broader context, what happens if cryptodev_cb_init()
fails and cryptodev_cb_cleanup() is later called? The cleanup function
cryptodev_cb_cleanup()->rte_free() might attempt to free dev->deq_cbs
even though the allocation failed. Does the cleanup path verify both
pointers are valid before attempting to free them, or does it assume
NULL pointers are safe to pass to rte_free()?