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: <CAM0EoMnEU1gLNn4XNbq=rG14iVh_XqU32P3y_8K8+fvRbmWrvA@mail.gmail.com>
Date: Wed, 3 Dec 2025 09:23:17 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Davide Caratti <dcaratti@...hat.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

Sorry, I totally forgot to add Petr in the original post, he's on Cc now..

On Tue, Dec 2, 2025 at 4:56 AM Davide Caratti <dcaratti@...hat.com> wrote:
>
> On Fri, Nov 28, 2025 at 03:52:53PM -0500, Jamal Hadi Salim wrote:
> > Hi Davide,
> >
> > On Fri, Nov 28, 2025 at 12:25 PM Davide Caratti <dcaratti@...hat.com> wrote:
>
> hello Jamal, thanks for your patience!
>
> [...]
>
> > > > diff --git a/net/sched/sch_ets.c b/net/sched/sch_ets.c
> > > > index 82635dd2cfa5..ae46643e596d 100644
> > > > --- a/net/sched/sch_ets.c
> > > > +++ b/net/sched/sch_ets.c
> > > > @@ -652,7 +652,7 @@ static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt,
> > > >       sch_tree_lock(sch);
> > > >
> > > >       for (i = nbands; i < oldbands; i++) {
> > > > -             if (i >= q->nstrict && q->classes[i].qdisc->q.qlen)
> > > > +             if (cl_is_active(&q->classes[i]))
> > > >                       list_del_init(&q->classes[i].alist);
> > > >               qdisc_purge_queue(q->classes[i].qdisc);
> > > >       }
> > >
> > > (nit)
> > >
> > > the reported problem is NULL dereference of q->classes[i].qdisc, then
> > > probably the 'Fixes' tag is an hash precedent to de6d25924c2a ("net/sched: sch_ets: don't
> > > peek at classes beyond 'nbands'"). My understanding is: the test on 'q->classes[i].qdisc'
> > > is no more NULL-safe after 103406b38c60 ("net/sched: Always pass notifications when
> > > child class becomes empty"). So we might help our friends  planning backports with something like:
> > >
> > > Fixes: de6d25924c2a ("net/sched: sch_ets: don't peek at classes beyond 'nbands'")
> > > Fixes: c062f2a0b04d ("net/sched: sch_ets: don't remove idle classes from the round-robin list")
> > >
> > > WDYT?
> >
> > I may be misreading your thought process, seems you are thinking the
> > null ptr deref is in change()?
> > The null ptr deref (and the uaf if you add a delay) is in dequeue
> > (ets_qdisc_dequeue()) i.e not in change.
>
> I understand this - it happens to DRR classes that are beyond 'nbands'
> after the call to ets_qdisc_change(). Since those queues can have some packets
> stored, in ets_qdisc_dequeue() you might have observed:
>
> 480                 cl = list_first_entry(&q->active, struct ets_class, alist);
> 481                 skb = cl->qdisc->ops->peek(cl->qdisc);
>
> with a "problematic" value in cl->qdisc. That's why I suggest to add
>
> [1] Fixes: de6d25924c2a ("net/sched: sch_ets: don't peek at classes beyond 'nbands'")
>

Ok, so that was the initial attempt to fix this issue?

> in the metadata.
>
> > If that makes sense, what would be a more appropriate Fixes?
>
> 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?

> > 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.

> In case it makes some
> sense, that would be a follow-up patch targeting net-next that I can test and send. Any
> feedback appreciated!
>

We'll see if it is worth it. Some more testing is needed.

cheers,
jamal


> thanks,
> --
> davide
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ