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] [day] [month] [year] [list]

Message-ID: <PKMd5btHYmJcKSiIJdtxQvZBEfuS4RQkBnE4M-TZkjUq_Rdj6Wgm8wDmX-p6rIkSRGDJN8ufn0HcDI6-r2lgibdSk7cn1mHIdbZEohJFKMg=@willsroot.io>
Date: Tue, 25 Nov 2025 04:20:13 +0000
From: William Liu <will@...lsroot.io>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Cong Wang <xiyou.wangcong@...il.com>, Stephen Hemminger <stephen@...workplumber.org>, Jamal Hadi Salim <jhs@...atatu.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, jschung2@...ton.me, savy@...t3mfailure.io
Subject: Re: [Bug 220774] New: netem is broken in 6.18

Part of the original issue was that alternative proposed fixes did not work and still allowed for local DOSes [1] [2].

An easy fix that was suggested was to not enqueue from the root [3][4]. However, this changes behavior that has existed since the beginning, immediately caused a new bug, and Hemminger mentioned that the original behavior was necessary for "trying to keep proper semantics and accounting especially when doing rate limits." An argument can be made that Cong's change doesn't violate manpage semantics, but that may still break user setups, just like the current scenario.

Jamal had a good idea on using tc_skb_ext extensions, but I pointed out a few implementation issues we would have to deal with [5]. From what I understood though, that solution would preserve all the existing behaviors and avoid the DOS bug. It's been a while so let me know if that is not the case. Otherwise, I can try to implement it - I am quite busy though so it might take a while.

On Tuesday, November 25th, 2025 at 3:16 AM, Jakub Kicinski <kuba@...nel.org> wrote:

> 
> 
> On Sat, 22 Nov 2025 10:14:50 -0800 Cong Wang wrote:
> 
> > > 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.
> 
> 
> I'm curious why we did.. Link?

The issue was due to filters redirecting packets iirc [6]. We decided to move with it and come back to it if someone did rely on this rare setup [7].

If anyone wants a quick refresher on the bug, please take a read at [6] as it contains all the details and issues.

[1] https://lore.kernel.org/netdev/20250701231306.376762-1-xiyou.wangcong@gmail.com/T/#u
[2] https://lore.kernel.org/netdev/20250707195015.823492-1-xiyou.wangcong@gmail.com/T/#u
[3] https://lore.kernel.org/netdev/20250713214748.1377876-1-xiyou.wangcong@gmail.com/T/#u
[4] https://lore.kernel.org/netdev/CAM0EoMmTZon=nFmLsDPKhDEzHruw701iV9=mq92At9oKo0LGpA@mail.gmail.com/T/#u
[5] https://lore.kernel.org/netdev/pGE9OHWRSf4oJwC4gS0oPonBy8_0WsDthxgLzBYGBtMVeT_EDc-HAz8NbhJxcWe0NEUrf_a7Fyq2op5FVFujfc2KyO-I38Yx_HlQhFwB0Cs=@willsroot.io/
[6] https://lore.kernel.org/netdev/CAM0EoMnd0nZxJW3zpEuBGWTwB3AnJSnj242f9hMpcLdBWdcbfQ@mail.gmail.com/
[7] https://lore.kernel.org/netdev/20250707142617.10849b9e@kernel.org/