[AMD Official Use Only - AMD Internal Distribution Only]

Hi Stephen,


We are checking the patches and doing the verification on our AMD setup. We 
will provide update on this. If possible, please share us the AI tool details, 
which you are using and steps used that will help us for future patch 
submission and code review.


Regards,
Venkat

-----Original Message-----
From: Stephen Hemminger <[email protected]>
Sent: Saturday, March 7, 2026 12:26 AM
To: Sebastian, Selwin <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/4] net/axgbe: fix resource leaks and OOB access

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


On Wed, 18 Feb 2026 08:40:58 -0800
Stephen Hemminger <[email protected]> wrote:

> Code review of the axgbe PMD identified several correctness bugs,
> primarily around resource management on error paths in device
> initialization and an out-of-bounds descriptor ring access.
>
> Patch 1 fixes multiple resource leak paths in eth_axgbe_dev_init():
>   - mac_addrs leaked when hash_mac_addrs allocation fails
>   - hash_mac_addrs leaked when phy_init() fails
>   - rte_intr_callback_register() return value unchecked
>   - DMA reset failure via hw_if.exit() logged but not propagated
>
> Patch 2 fixes wrapper_rx_desc_init() which only releases the current
> queue on mbuf allocation failure, leaking all mbufs from previously
> initialized queues.
>
> Patch 3 adds pthread_mutex_destroy() calls in axgbe_dev_close() for
> the four mutexes created during init.
>
> Patch 4 fixes an out-of-bounds read in both Rx and Tx descriptor
> status functions where desc[idx + offset] can exceed the ring size.
> The offset is now folded into the index before masking.
>
>
> Stephen Hemminger (4):
>   net/axgbe: fix resource leaks in device init error paths
>   net/axgbe: fix Rx queue leak on descriptor init failure
>   net/axgbe: destroy mutexes on device close
>   net/axgbe: fix descriptor status out-of-bounds access

Since these were code review generated fixes, still holding off for maintainer 
of this driver to verify

Reply via email to