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: <aSH9mvol/++40XT0@pop-os.localdomain>
Date: Sat, 22 Nov 2025 10:14:50 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Stephen Hemminger <stephen@...workplumber.org>,
	Jamal Hadi Salim <jhs@...atatu.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 05:55:56PM -0800, Jakub Kicinski 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 

This is not true, I warned you and Jamal with precisely the mq+netem
combination before applying the patch, both of you chose to ignore.

> the mq+netem hierarchy?

This would make the code even uglier, it is already ugly enough to
hard-code and single out this case in the code.

Not to mention there could be other combinations we don't know yet.

We need to revert it and fix the original issue with changing the
problematic duplication behavior.

Regards,
Cong