netdev - Re: [PATCH net] net/sched: ets: Always remove class from active list before deleting in ets_qdisc

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: <aTFgQxYZfl5MAfNE@dcaratti.users.ipa.redhat.com>
Date: Thu, 4 Dec 2025 11:19:47 +0100
From: Davide Caratti <dcaratti@...hat.com>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: davem@...emloft.net, kuba@...nel.org, edumazet@...gle.com,
	pabeni@...hat.com, xiyou.wangcong@...il.com, jiri@...nulli.us,
	netdev@...r.kernel.org, horms@...nel.org,
	zdi-disclosures@...ndmicro.com, w@....eu, security@...nel.org,
	tglx@...utronix.de, victor@...atatu.com,
	Petr Machata <petrm@...dia.com>
Subject: Re: [PATCH net] net/sched: ets: Always remove class from active list
 before deleting in ets_qdisc_change

On Wed, Dec 03, 2025 at 09:23:17AM -0500, Jamal Hadi Salim wrote:

> > the line you are changing in the patch above was added with:
> >
> > c062f2a0b04d ("net/sched: sch_ets: don't remove idle classes from the round-robin list")
> >
> > and the commit message said:
> >
> 
> > << we can remove 'q->classes[i].alist' only if DRR class 'i' was part of the active
> >    list. In the ETS scheduler DRR classes belong to that list only if the queue length
> >    is greater than zero >>
> >
> > this assumption on the queue length is no more valid, maybe it has never been valid :),
> > hence my suggestion to add also
> >
> > [2] Fixes: c062f2a0b04d ("net/sched: sch_ets: don't remove idle classes from the round-robin list")
> >
> 
> ok, so this seems to be a followup attempt to the first one.
> I have a question: Shouldnt we be listing all the commits in Fixes if
> subsequent patches are fixing a previous one? Example, this one has a
> Fixes: de6d25924c2a - which is the previous one? IOW, would it not be
> fine to only mention c062f2a0b04d and not de6d25924c2a?

right - I didn't see that c062f2a0b04d has the 'Fixes' tag for
de6d25924c2a. Then also the single 'Fixes' tag equal to de6d25924c2a
should be sufficient to track all the needed backports. 
> 
> > > BTW, is that q->classes[i].qdisc = NULL even needed after this?
> > > It was not clear whether it guards against something else that was not
> > > obvious from inspection.
> >
> > That NULL assignment is done in ets_qdisc_change() since the beginning: for classes
> > beyond 'nbands' we had
> >
> >         for (i = q->nbands; i < oldbands; i++) {
> >                 qdisc_put(q->classes[i].qdisc);
> >                 memset(&q->classes[i], 0, sizeof(q->classes[i]));
> >
> > in the very first implementation of sch_ets that memset() was wrongly overwriting 'alist'.
> 
> Ok. makes sense - i see it in the original patch from Petr.
> 
> > The NULL assignment is not strictly necessary, but any value of 'q->classes[i].qdisc'
> > is either a UAF or a NULL dereference when 'i' is greater or equal to 'q->nbands'.
> 
> I agree - before this one liner fix. I do think it is not necessary
> any longer, but wont touch it for now in case there are other
> dependencies
> 
> > I see that ETS sometimes assigns the noop qdisc there: maybe we can assign that to
> > 'q->classes[i].qdisc' when 'i' is greater or equal to 'q->nbands', instead of NULL ?
> 
> I wouldnt go that far. What i can tell you is removing it didnt matter
> in both what i and Victor tested.
> 
> > so the value of 'q->classes[i].qdisc' is a valid pointer all the times?
> 
> Well, I don't think the nstrict classes should have gone into that
> alist to begin with (looking at the trick test that  made you issue
> the first commit - that is what the test was achieving) and since that
> doesnt happen anymore we dont need to worry about it.

right, because cl_is_active() would return false for strict priority classes.

Reviewed-by: Davide Caratti <dcaratti@...hat.com>

thanks for fixing this!
-- 
davide