linux-kernel - Re: [PATCH net v4] net: axienet: safely drop oversized RX frames

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iJ9iAP0GXk_qmzu+2MjWHi_NDOjG1QdLAiY1YSj+RjZQw@mail.gmail.com>
Date: Fri, 16 May 2025 02:02:16 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Can Ayberk Demir <ayberkdemir@...il.com>
Cc: netdev@...r.kernel.org, Radhey Shyam Pandey <radhey.shyam.pandey@....com>, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S . Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Michal Simek <michal.simek@....com>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Suraj Gupta <suraj.gupta2@....com>
Subject: Re: [PATCH net v4] net: axienet: safely drop oversized RX frames

On Fri, May 16, 2025 at 1:44 AM Can Ayberk Demir <ayberkdemir@...il.com> wrote:
>
> From: Can Ayberk DEMIR <ayberkdemir@...il.com>
>
> In AXI Ethernet (axienet) driver, receiving an Ethernet frame larger
> than the allocated skb buffer may cause memory corruption or kernel panic,
> especially when the interface MTU is small and a jumbo frame is received.
>
> This bug was discovered during testing on a Kria K26 platform. When an
> oversized frame is received and `skb_put()` is called without checking
> the tailroom, the following kernel panic occurs:
>
>   skb_panic+0x58/0x5c
>   skb_put+0x90/0xb0
>   axienet_rx_poll+0x130/0x4ec
>   ...
>   Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt
>
> Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
>
> Signed-off-by: Can Ayberk DEMIR <ayberkdemir@...il.com>
> Tested-by: Suraj Gupta <suraj.gupta2@....com>
> ---
> Changes in v4:
> - Moved Fixes: tag before SOB as requested
> - Added Tested-by tag from Suraj Gupta
>
> Changes in v3:
> - Fixed 'ndev' undeclared error → replaced with 'lp->ndev'
> - Added rx_dropped++ for statistics
> - Added Fixes: tag
>
> Changes in v2:
> - This patch addresses style issues pointed out in v1.
> ---
>  .../net/ethernet/xilinx/xilinx_axienet_main.c | 47 +++++++++++--------
>  1 file changed, 28 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 1b7a653c1f4e..7a12132e2b7c 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -1223,28 +1223,37 @@ static int axienet_rx_poll(struct napi_struct *napi, int budget)
>                         dma_unmap_single(lp->dev, phys, lp->max_frm_size,
>                                          DMA_FROM_DEVICE);
>
> -                       skb_put(skb, length);
> -                       skb->protocol = eth_type_trans(skb, lp->ndev);
> -                       /*skb_checksum_none_assert(skb);*/
> -                       skb->ip_summed = CHECKSUM_NONE;
> -
> -                       /* if we're doing Rx csum offload, set it up */
> -                       if (lp->features & XAE_FEATURE_FULL_RX_CSUM) {
> -                               csumstatus = (cur_p->app2 &
> -                                             XAE_FULL_CSUM_STATUS_MASK) >> 3;
> -                               if (csumstatus == XAE_IP_TCP_CSUM_VALIDATED ||
> -                                   csumstatus == XAE_IP_UDP_CSUM_VALIDATED) {
> -                                       skb->ip_summed = CHECKSUM_UNNECESSARY;
> +                       if (unlikely(length > skb_tailroom(skb))) {

If really the NIC copied more data than allowed, we already have
corruption of kernel memory.

Dropping the packet here has undetermined behavior.

If the NIC only reports the big length but has not performed any DMA,
then the skb can be recycled.
No point freeing it, and re-allocate a new one.