Re: [RFC Patch net-next 0/2] net_sched: Move GSO segmentation to root qdisc

[Jamal Hadi Salim <jhs@mojatatu.com>]

Hi,

On Fri, Mar 13, 2026 at 9:38 AM Mingi Cho <mgcho.minic@gmail.com> wrote:
>
> On Thu, Mar 12, 2026 at 04:21:07PM -0400, Jamal Hadi Salim wrote:
> > On Thu, Mar 12, 2026 at 12:58 PM Mingi Cho <mgcho.minic@gmail.com> wrote:
> > >
> > > On Tue, Jul 01, 2025 at 04:29:13PM -0700, Cong Wang wrote:
> > > > This patchset attempts to move the GSO segmentation in Qdisc layer from
> > > > child qdisc up to root qdisc. It fixes the complex handling of GSO
> > > > segmentation logic and unifies the code in a generic way. The end result
> > > > is cleaner (see the patch stat) and hopefully keeps the original logic
> > > > of handling GSO.
> > > >
> > > > This is an architectural change, hence I am sending it as an RFC. Please
> > > > check each patch description for more details. Also note that although
> > > > this patchset alone could fix the UAF reported by Mingi, the original
> > > > UAF can also be fixed by Lion's patch [1], so this patchset is just an
> > > > improvement for handling GSO segmentation.
> > > >
> > > > TODO: Add some selftests.
> > > >
> > > > 1. https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/
> > > >
> > > > ---
> > > > Cong Wang (2):
> > > >   net_sched: Move GSO segmentation to root qdisc
> > > >   net_sched: Propagate per-qdisc max_segment_size for GSO segmentation
> > > >
> > > >  include/net/sch_generic.h |  4 +-
> > > >  net/core/dev.c            | 52 +++++++++++++++++++---
> > > >  net/sched/sch_api.c       | 14 ++++++
> > > >  net/sched/sch_cake.c      | 93 +++++++++++++--------------------------
> > > >  net/sched/sch_netem.c     | 32 +-------------
> > > >  net/sched/sch_taprio.c    | 76 +++++++-------------------------
> > > >  net/sched/sch_tbf.c       | 59 +++++--------------------
> > > >  7 files changed, 123 insertions(+), 207 deletions(-)
> > > >
> > > > --
> > > > 2.34.1
> > > >
> > >
> > > Hi Cong,
> > >
> > > I tested the proposed patch and found that the reported bug was fixed. A qlen mismatch between Qdiscs can potentially cause UAF, so I believe this patch needs to be applied.
> > >
> > > When executing the PoC on the latest kernel without the patch applied, a warning message occurs in drr_dequeue() as shown below.
> > >
> > > Before applying the patch:
> > >
> > > root@test:~# ./poc
> > > qdisc drr 1: dev lo root refcnt 2
> > > qdisc tbf 2: dev lo parent 1:1 rate 1Mbit burst 1514b lat 50.0ms
> > > qdisc choke 3: dev lo parent 2:1 limit 2p min 1p max 2p
> > > [    7.588847] drr_dequeue: tbf qdisc 2: is non-work-conserving?
> > >
> > > Testing after applying the patch to the v6.17 kernel shows that the warning message has disappeared.
> > >
> > > After applying the patch:
> > >
> > > root@test:~# ./poc
> > > qdisc drr 1: dev lo root refcnt 2
> > > qdisc tbf 2: dev lo parent 1:1 rate 1Mbit burst 1514b lat 50.0ms
> > > qdisc choke 3: dev lo parent 2:1 limit 2p min 1p max 2p
> >
> > Please test against latest net-next kernel then report back on the UAF
> > - not a "potential" but a real one.
> >
> > cheers,
> > jamal
>
> As seen in a recent patch (https://lore.kernel.org/netdev/20260114160243.913069-3-jhs@mojatatu.com/), it was possible to trigger a UAF using the QFQ qdisc when qlen was handled incorrectly. I don't think this is the only way to trigger a UAF. Since it is obvious that qlen is also being handled incorrectly during the GSO segment processing, I believe it would be better to remove this potential risk.
>

I may not be remembering the sequence of events correctly, and i am
not sure if after all this time if that potential UAF hasnt been
resolved. Your repro was fixed by:
https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

Typically, a message like "is non-work-conserving?" means you have
some bogus hierarchy. Find a way to create what you suggested is a
potential UAF, and I will be more than happy to invest time.

cheers,
jamal