Netdev List
 help / color / mirror / Atom feed
From: Cong Wang <xiyou.wangcong@gmail.com>
To: Victor Nogueira <victor@mojatatu.com>
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
	pabeni@redhat.com, jhs@mojatatu.com, jiri@resnulli.us,
	horms@kernel.org, stephen@networkplumber.org,
	netdev@vger.kernel.org
Subject: Re: [RFC PATCH net-next v3] net/sched: Introduce qdisc quirk_chk op
Date: Thu, 27 Nov 2025 11:09:11 -0800	[thread overview]
Message-ID: <aSih15MrrRud2qho@pop-os.localdomain> (raw)
In-Reply-To: <20251127164935.572746-1-victor@mojatatu.com>

On Thu, Nov 27, 2025 at 01:49:35PM -0300, Victor Nogueira wrote:
> There is a pattern of bugs that end up creating UAFs or null ptr derefs.
> The majority of these bugs follow the formula below:
> a) create a nonsense hierarchy of qdiscs which has no practical value,
> b) start sending packets
> Optional 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
> work-conserving qdiscs somewhere in the hierarchy
> Optional d dependent on c) send more packets
> e) profit
> 
> Current init/change qdisc APIs are localised to validate only within the
> constraint of a single qdisc. So catching #a or #c is a challenge. Our
> policy, when said bugs are presented, is to "make it work" by modifying
> generally used data structures and code, but these come at the expense of
> adding special checks for corner cases which are nonsensical to begin with.
> 
> The goal of this patchset is to create an equivalent to PCI quirks, which
> will catch nonsensical hierarchies in #a and #c and reject such a config.
> 
> With that in mind, we are proposing the addition of a new qdisc op
> (quirk_chk). We introduce, as a first example, the quirk_chk op to netem.
> Its purpose here is to validate whether the user is attempting to add
> nested netem duplicates in the same qdisc tree branch which will be
> forbidden.

As I already explained in your v2, this does not justify the ugliness of
the code. It was wrong to introduce the ugly checks from the very
beginning, therefore, it makes no sense to keep adding more ugly code to
fix it. Reverting it is the best option, as far as I can see.

> 
> Here is an example that should now work:

Oh, I am glad to see you and your boss finally acknowledge breaking
users. :)

> 
> DEV="eth0"
> NUM_QUEUES=4
> DUPLICATE_PERCENT="5%"
> 
> tc qdisc del dev $DEV root > /dev/null 2>&1
> tc qdisc add dev $DEV root handle 1: mq
> 
> for i in $(seq 1 $NUM_QUEUES); do
>     HANDLE_ID=$((i * 10))
>     PARENT_ID="1:$i"
>     tc qdisc add dev $DEV parent $PARENT_ID handle \
>         ${HANDLE_ID}: netem duplicate $DUPLICATE_PERCENT
> done

Looks identical to Ji'Soo's report:
https://bugzilla.kernel.org/show_bug.cgi?id=220774#c0

without crediting Ji-Soo... What's wrong with crediting reporters fairly?

> 
> Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Victor Nogueira <victor@mojatatu.com>

Nacked-by: Cong Wang <xiyou.wangcong@gmail.com>

Note: My response is just for record purpose, I have to reject it for record
because I don't want to get blamed for being disrespectful to our users.
This does not aim to stop you and your boss pushing your agenda in the open
source community. And you don't need to respond against your boss' will, this is
perfectly understood. I will bring this up for other maintainers at LPC, since
I care about the open source community. Let record speak.

Hope this makes sense to you. If there is anything I could help you,
please don't hesitate to reach out to me directly at any time.

Regards,
Cong Wang

      reply	other threads:[~2025-11-27 19:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-27 16:49 [RFC PATCH net-next v3] net/sched: Introduce qdisc quirk_chk op Victor Nogueira
2025-11-27 19:09 ` Cong Wang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aSih15MrrRud2qho@pop-os.localdomain \
    --to=xiyou.wangcong@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stephen@networkplumber.org \
    --cc=victor@mojatatu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox