drivers/net/ethernet/marvell/octeontx2/nic/cn20k.c | 2 ++ drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c | 2 ++ 2 files changed, 4 insertions(+)
otx2_pool_aq_init() frees pool->stack when mailbox sync or retry
allocation fails, but leaves the pointer unchanged. Later,
otx2_sq_aura_pool_init() unwinds the partial setup through
otx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific
cn20k_pool_aq_init() implementation has the same bug in
its corresponding error path.
Set pool->stack to NULL immediately after the local free so the shared
cleanup path does not free the same stack again while cleaning up
partially initialized pool state.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still present in
v7.1-rc3.
Runtime validation was not performed because reproducing this path
requires OcteonTX2/CN20K hardware.
Fixes: caa2da34fd25 ("octeontx2-pf: Initialize and config queues")
Fixes: d322fbd17203 ("octeontx2-pf: Initialize cn20k specific aura and pool contexts")
Cc: stable@vger.kernel.org
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
---
drivers/net/ethernet/marvell/octeontx2/nic/cn20k.c | 2 ++
drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn20k.c b/drivers/net/ethernet/marvell/octeontx2/nic/cn20k.c
index a5a8f4558717..dbf173196608 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/cn20k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/cn20k.c
@@ -619,11 +619,13 @@ static int cn20k_pool_aq_init(struct otx2_nic *pfvf, u16 pool_id,
err = otx2_sync_mbox_msg(&pfvf->mbox);
if (err) {
qmem_free(pfvf->dev, pool->stack);
+ pool->stack = NULL;
return err;
}
aq = otx2_mbox_alloc_msg_npa_cn20k_aq_enq(&pfvf->mbox);
if (!aq) {
qmem_free(pfvf->dev, pool->stack);
+ pool->stack = NULL;
return -ENOMEM;
}
}
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index 971fcab1c248..3d253132a17f 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -1482,11 +1482,13 @@ int otx2_pool_aq_init(struct otx2_nic *pfvf, u16 pool_id,
err = otx2_sync_mbox_msg(&pfvf->mbox);
if (err) {
qmem_free(pfvf->dev, pool->stack);
+ pool->stack = NULL;
return err;
}
aq = otx2_mbox_alloc_msg_npa_aq_enq(&pfvf->mbox);
if (!aq) {
qmem_free(pfvf->dev, pool->stack);
+ pool->stack = NULL;
return -ENOMEM;
}
}
--
2.34.1
On Fri, May 15, 2026 at 11:18:26PM +0800, Dawei Feng wrote:
> otx2_pool_aq_init() frees pool->stack when mailbox sync or retry
> allocation fails, but leaves the pointer unchanged. Later,
> otx2_sq_aura_pool_init() unwinds the partial setup through
> otx2_aura_pool_free(), which frees pool->stack again. The CN20K-specific
> cn20k_pool_aq_init() implementation has the same bug in
> its corresponding error path.
>
> Set pool->stack to NULL immediately after the local free so the shared
> cleanup path does not free the same stack again while cleaning up
> partially initialized pool state.
>
> The bug was first flagged by an experimental analysis tool we are
> developing for kernel memory-management bugs while analyzing
> v6.13-rc1. The tool is still under development and is not yet publicly
> available. Manual inspection confirms that the bug is still present in
> v7.1-rc3.
>
> Runtime validation was not performed because reproducing this path
> requires OcteonTX2/CN20K hardware.
>
> Fixes: caa2da34fd25 ("octeontx2-pf: Initialize and config queues")
> Fixes: d322fbd17203 ("octeontx2-pf: Initialize cn20k specific aura and pool contexts")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
There is an AI generated review of this patch available on sashiko.dev
I believe the issues raised there can be considered in the context of
possible follow-up. I do not believe they should effect the progress
of this patch.
…
> Set pool->stack to NULL immediately after the local free so the shared
…
so that?
How do you think about to avoid a bit of duplicate source code
in affected function implementations?
https://elixir.bootlin.com/linux/v7.1-rc3/source/drivers/net/ethernet/marvell/octeontx2/nic/cn20k.c#L615-L629
https://elixir.bootlin.com/linux/v7.1-rc3/source/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c#L1478-L1492
> The bug was first flagged by an experimental analysis tool we are
> developing for kernel memory-management bugs while analyzing
> v6.13-rc1. The tool is still under development and is not yet publicly
> available. Manual inspection confirms that the bug is still present in
> v7.1-rc3.
Under which circumstances will the mentioned software revision gap
be adjusted accordingly?
Regards,
Markus
On Mon, May 18, 2026 at 11:23:30AM +0200, Markus Elfring wrote: > … > > Set pool->stack to NULL immediately after the local free so the shared > … > so that? > > How do you think about to avoid a bit of duplicate source code > in affected function implementations? > https://elixir.bootlin.com/linux/v7.1-rc3/source/drivers/net/ethernet/marvell/octeontx2/nic/cn20k.c#L615-L629 > https://elixir.bootlin.com/linux/v7.1-rc3/source/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c#L1478-L1492 > > > > The bug was first flagged by an experimental analysis tool we are > > developing for kernel memory-management bugs while analyzing > > v6.13-rc1. The tool is still under development and is not yet publicly > > available. Manual inspection confirms that the bug is still present in > > v7.1-rc3. > > Under which circumstances will the mentioned software revision gap > be adjusted accordingly? > > Regards, > Markus > Hi, This is the semi-friendly patch-bot of Greg Kroah-Hartman. Markus, you seem to have sent a nonsensical or otherwise pointless review comment to a patch submission on a Linux kernel developer mailing list. I strongly suggest that you not do this anymore. Please do not bother developers who are actively working to produce patches and features with comments that, in the end, are a waste of time. Patch submitter, please ignore Markus's suggestion; you do not need to follow it at all. The person/bot/AI that sent it is being ignored by almost all Linux kernel maintainers for having a persistent pattern of behavior of producing distracting and pointless commentary, and inability to adapt to feedback. Please feel free to also ignore emails from them. thanks, greg k-h's patch email bot
© 2016 - 2026 Red Hat, Inc.