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] [day] [month] [year] [list]
Message-ID:
 <BL3PR12MB65717939233B7E5F94BF7E43C99CA@BL3PR12MB6571.namprd12.prod.outlook.com>
Date: Mon, 19 May 2025 05:17:33 +0000
From: "Gupta, Suraj" <Suraj.Gupta2@....com>
To: Eric Dumazet <edumazet@...gle.com>, Can Ayberk Demir
	<ayberkdemir@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Pandey, Radhey Shyam"
	<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>, "Simek, Michal" <michal.simek@....com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net v4] net: axienet: safely drop oversized RX frames

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Eric Dumazet <edumazet@...gle.com>
> Sent: Friday, May 16, 2025 2:32 PM
> To: Can Ayberk Demir <ayberkdemir@...il.com>
> Cc: netdev@...r.kernel.org; Pandey, Radhey Shyam
> <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>; Simek, Michal <michal.simek@....com>; linux-arm-
> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; Gupta, Suraj
> <Suraj.Gupta2@....com>
> Subject: Re: [PATCH net v4] net: axienet: safely drop oversized RX frames
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> 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.

Agreed, this may not be the right place to drop the packet. Please check jumbo frame configurations. We suspect memory for jumbo frames (represented by "xlnx,rxmem" in DT) might not be
sufficient in the design. This memory size is checked in the driver before enabling jumbo frame support.