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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ