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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 17 Mar 2023 22:21:17 -0700 From: Jakub Kicinski <kuba@...nel.org> To: Jochen Henneberg <jh@...neberg-systemdesign.com> Cc: netdev@...r.kernel.org, Giuseppe Cavallaro <peppe.cavallaro@...com>, Alexandre Torgue <alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>, Ong Boon Leong <boon.leong.ong@...el.com>, linux-stm32@...md-mailman.stormreply.com, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH net V2 1/2] net: stmmac: Premature loop termination check was ignored on rx On Thu, 16 Mar 2023 08:59:39 +0100 Jochen Henneberg wrote: > The premature loop termination check makes sense only in case of the > jump to read_again where the count may have been updated. But > read_again did not include the check. > > Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support") > Signed-off-by: Jochen Henneberg <jh@...neberg-systemdesign.com> > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index e4902a7bb61e..ea51c7c93101 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -5221,10 +5221,10 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue) > len = 0; > } > > +read_again: > if (count >= limit) > break; Are you sure? Can you provide more detailed analysis? Do you observe a problem / error in real life or is this theoretical? As far as I can tell only path which jumps to read_again after doing count++ is via the drain_data jump, but I can't tell how it's discarding subsequent segments in that case.. > -read_again: > buf1_len = 0; > buf2_len = 0; > entry = next_entry;
Powered by blists - more mailing lists