linux-kernel - Re: [Bug 220774] New: netem is broken in 6.18

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: <CAM0EoMnoocCVQbky3NQZt1kkHbEYsKgTEspBd4YbfqmSd=1=wQ@mail.gmail.com>
Date: Sat, 22 Nov 2025 12:16:32 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Stephen Hemminger <stephen@...workplumber.org>, Cong Wang <xiyou.wangcong@...il.com>, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org, will@...lsroot.io, 
	jschung2@...ton.me, savy@...t3mfailure.io
Subject: Re: [Bug 220774] New: netem is broken in 6.18

On Fri, Nov 21, 2025 at 8:55 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Fri, 21 Nov 2025 16:13:22 -0800 Stephen Hemminger wrote:
> > On Fri, 21 Nov 2025 13:45:06 -0800
> > Cong Wang <xiyou.wangcong@...il.com> wrote:
> >
> > > On Fri, Nov 21, 2025 at 07:52:37AM -0500, Jamal Hadi Salim wrote:
> > >
> > > > jschung2@...ton.me: Can you please provide more details about what you
> > > > are trying to do so we can see if a different approach can be
> > > > prescribed?
> > > >
> > >
> > > An alternative approach is to use eBPF qdisc to replace netem, but:
> > > 1) I am not sure if we could duplicate and re-inject a packet in eBPF Qdisc
> > > 2) I doubt everyone wants to write eBPF code when they already have a
> > > working cmdline.
> > >
> > > BTW, Jamal, if your plan is to solve them one by one, even if it could work,
> > > it wouldn't scale. There are still many users don't get hit by this
> > > regression yet (not until hitting LTS or major distro).
> >
> > The bug still needs to be fixed.
> > eBPF would still have the same kind of issues.
>
> I guess we forgot about mq.. IIRC mq doesn't come into play in
> duplication, we should be able to just adjust the check to allow
> the mq+netem hierarchy?

Yes, something like that - but imo it would be fugly to do that check
in current code just for mq.
I proposed to add another qdisc ops which checks for cross-qdisc
semantics. This ops will be invoked by a qdisc's change/init - sort of
what pci quirks ops does. For example in this case it will disallow
setting up netem when it would cause loops but have the quirck checker
allow multiple children such as with mq with as long as none is
looping. I believe some sort of "feature bits" checking should work
here.

The majority of the bugs we are dealing with follow the formula of:
a) create a nonsense hierarchy of qdiscs which has no pratical value,
b) start sending packets
c) netlink cmds to change hierarchy some more; It's more fun if you
can get packets stuck - the formula in this case includes non-working
conserving qdsiscs somewhere in the hierarchy
d) send more packets
e) profit
Current init/change are not really designed to catch things that deal
with children or parents, so catching #a or #c is a challenge. We do
"make it work" eventually but it keeps adding these "checks" for
nonsense setups adds more unnecessary code.

Perhaps its time to start this effort and use this specific scenario
as a use case.

cheers,
jamal