|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