[PATCH net] net: ena: avoid double-counting TX DMA mappings on failure

[PATCH net] net: ena: avoid double-counting TX DMA mappings on failure

[Avi Weiss]

ena_tx_map_skb() increments tx_info->num_of_bufs after each successful
DMA mapping. If a later fragment mapping fails, the error path adds the
fragment index to this count before calling ena_unmap_tx_buff(). This
can cause DMA unmapping of buffers that were never mapped and
out-of-bounds access to the buffer array.

Remove the extra increment so that cleanup uses only the number of
successfully mapped buffers.

Discovered by comparing the in-tree ENA driver with Amazon's standalone
ENA driver.

Compiled with W=1 under x86_64 defconfig and allmodconfig configurations.
Fixes: 38005ca816a7 ("net: ena: add functions for handling Low Latency Queues in ena_netdev")
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
---
Already fixed in Amazon's standalone ENA driver:
https://github.com/amzn/amzn-drivers/commit/1d6a78cebd2d7c38b4dbdee572ab3d3755086248

drivers/net/ethernet/amazon/ena/ena_netdev.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 7eb6456ed0d5..e0df628e1df6 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -2608,7 +2608,6 @@ static int ena_tx_map_skb(struct ena_ring *tx_ring,
 
 	tx_info->skb = NULL;
 
-	tx_info->num_of_bufs += i;
 	ena_unmap_tx_buff(tx_ring, tx_info);
 
 	return -EINVAL;

base-commit: 30c71476d842b094651bd7712f6c8ee8716147d0
-- 
2.43.0

Re: [PATCH net] net: ena: avoid double-counting TX DMA mappings on failure

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] net: ena: avoid double-counting TX DMA mappings on failure

[Arthur Kiyanovski]

On Mon, 09 Nov 2026 14:39:34 +0200, Avi Weiss <thnkslprpt@gmail.com> wrote:
> diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
> index 7eb6456ed0d5..e0df628e1df6 100644
> --- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
> +++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
> @@ -2608,7 +2608,6 @@ static int ena_tx_map_skb(struct ena_ring *tx_ring,
>  
>  	tx_info->skb = NULL;
>  
> -	tx_info->num_of_bufs += i;
>  	ena_unmap_tx_buff(tx_ring, tx_info);
>  
>  	return -EINVAL;

Like you wrote this one has already been applied to the amzn-drivers
repository:

https://github.com/amzn/amzn-drivers/commit/1d6a78cebd2d7c38b4dbdee572ab3d3755086248

Therefore please do the following:

1. Add a From: tag to give credit to Evgeny Ostrovsky, who wrote this fix 
   (without leading "-"):

- From: Evgeny Ostrovsky <evostrov@amazon.com>

This should be first line before "ena_tx_map_skb() increme..."

2. Evgeny has agreed, please also add (without leading "-"):

- Signed-off-by: Evgeny Ostrovsky <evostrov@amazon.com>

It should be added before your Signed-off-by:

-- 
Arthur Kiyanovski <akiyano@amazon.com>

Re: [PATCH net] net: ena: avoid double-counting TX DMA mappings on failure

[Jakub Kicinski]

On Wed, 11 Nov 2026 23:39:58 +0000 Arthur Kiyanovski wrote:
> Therefore please do the following:
> 
> 1. Add a From: tag to give credit to Evgeny Ostrovsky, who wrote this fix 
>    (without leading "-"):
> 
> - From: Evgeny Ostrovsky <evostrov@amazon.com>

Unclear whether that's warranted TBH.
Avi is making the effort to upstream the fix, they deserve the credit.

> This should be first line before "ena_tx_map_skb() increme..."
> 
> 2. Evgeny has agreed, please also add (without leading "-"):
> 
> - Signed-off-by: Evgeny Ostrovsky <evostrov@amazon.com>

SoB indeed seems appropriate if the patch is based on prior work.

RE: [PATCH net] net: ena: avoid double-counting TX DMA mappings on failure

[Kiyanovski, Arthur]

> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Wednesday, November 11, 2026 5:11 PM
> To: Kiyanovski, Arthur <akiyano@amazon.com>
> Cc: Avi Weiss <thnkslprpt@gmail.com>; Arinzon, David
> <darinzon@amazon.com>; netdev@vger.kernel.org; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S . Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> Subject: RE: [EXTERNAL] [PATCH net] net: ena: avoid double-counting TX DMA
> mappings on failure
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
> 
> 
> 
> On Wed, 11 Nov 2026 23:39:58 +0000 Arthur Kiyanovski wrote:
> > Therefore please do the following:
> >
> > 1. Add a From: tag to give credit to Evgeny Ostrovsky, who wrote this fix
> >    (without leading "-"):
> >
> > - From: Evgeny Ostrovsky <evostrov@amazon.com>
> 
> Unclear whether that's warranted TBH.
> Avi is making the effort to upstream the fix, they deserve the credit.
> 
> > This should be first line before "ena_tx_map_skb() increme..."
> >
> > 2. Evgeny has agreed, please also add (without leading "-"):
> >
> > - Signed-off-by: Evgeny Ostrovsky <evostrov@amazon.com>
> 
> SoB indeed seems appropriate if the patch is based on prior work.

Jakub,

The commit code (as well as the other 2 that were already merged)
Are copies of fixes that we already published in our github driver. 

This is the first time I encountered such a case so I searched
how to give credit to the person who originally implemented the fixes.

If you feel like SOB is enough I'm OK with it.

Thanks,
Arthur