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

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Thu Apr 16 16:59:00 CEST 2026


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: 1c3ffb95595e ("cryptodev: add enqueue and dequeue callbacks")
Author: Daniil Iskhakov <dish at amicon.ru>
Subject: [PATCH] cryptodev: reset resource pointers in init error path

This patch addresses a potential double-free issue in the cryptodev
callback initialization error path by setting freed pointers to NULL.

> 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 change fully address the double-free concern? The patch sets
dev->enq_cbs to NULL after freeing it in cryptodev_cb_init(), which
prevents a subsequent cryptodev_cb_cleanup() from double-freeing
dev->enq_cbs. However, does the error path also need to set
dev->deq_cbs to NULL if the cleanup logic in cryptodev_cb_cleanup()
could be called after this function returns an error?

Looking at the typical cleanup pattern, does cryptodev_cb_cleanup()
check both pointers independently before freeing them? If so, when
cryptodev_cb_init() fails after successfully allocating dev->enq_cbs
but before successfully allocating dev->deq_cbs, dev->deq_cbs might
contain an uninitialized value. Does the cleanup code handle this case,
or should dev->deq_cbs also be explicitly set to NULL in this error
path?


More information about the test-report mailing list