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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <AS8PR04MB8849AC9B20849B615AD5B67196FA2@AS8PR04MB8849.eurprd04.prod.outlook.com>
Date: Tue, 18 Feb 2025 09:02:57 +0000
From: Claudiu Manoil <claudiu.manoil@....com>
To: Wei Fang <wei.fang@....com>, Vladimir Oltean <vladimir.oltean@....com>,
	Clark Wang <xiaoning.wang@....com>, "andrew+netdev@...n.ch"
	<andrew+netdev@...n.ch>, "davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org"
	<kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>
CC: Ioana Ciornei <ioana.ciornei@....com>, "Y.B. Lu" <yangbo.lu@....com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>
Subject: RE: [PATCH net 1/8] net: enetc: fix the off-by-one issue in
 enetc_map_tx_buffs()



> -----Original Message-----
> From: Wei Fang <wei.fang@....com>
> Sent: Tuesday, February 18, 2025 4:03 AM
[,,,]
> Subject: RE: [PATCH net 1/8] net: enetc: fix the off-by-one issue in
> enetc_map_tx_buffs()
> 
> > > -----Original Message-----
> > > From: Wei Fang <wei.fang@....com>
> > > Sent: Monday, February 17, 2025 11:39 AM
> > [...]
> > > Subject: [PATCH net 1/8] net: enetc: fix the off-by-one issue in
> > > enetc_map_tx_buffs()
> > >
> > > When the DMA mapping error occurs, it will attempt to free 'count + 1'
> >
> > Hi Wei,
> > Are you sure?
> >
> > dma_err occurs before count is incremented, at least that's the design.
> >
> > First step already contradicts your claim:
> > ```
> > static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb)
> > { [...]
> > 	int i, count = 0;
> > [...]
> > 	dma = dma_map_single(tx_ring->dev, skb->data, len,
> DMA_TO_DEVICE);
> > 	if (unlikely(dma_mapping_error(tx_ring->dev, dma)))
> > 		goto dma_err;
> >
> > ===> count is 0 on goto path!
> > [...]
> > 	count++;
> > ```
> >
> 
> Hi Claudiu,
> 
> I think it's fine in your case, the count is 0, and the tx_swbd is not set,
> so it's unnecessary to call enetc_free_tx_frame() in the dma_err path.
> 

enetc_free_tx_frame() call on dma_err path is still needed for count 0 because
it needs to free the skb.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ