Netdev List
 help / color / mirror / Atom feed
From: yang zhuorao <alexyoung0@163.com>
To: aconole@redhat.com, i.maximets@ovn.org
Cc: echaudro@redhat.com, security@kernel.org, dev@openvswitch.org,
	netdev@vger.kernel.org, pabeni@redhat.com, kuba@kernel.org,
	horms@kernel.org, edumazet@google.com, davem@davemloft.net
Subject: Re: [net] net: openvswitch: fix stack exhaustion from unaccounted clone_execute() recursion
Date: Wed, 29 Jul 2026 14:19:16 +0800	[thread overview]
Message-ID: <178530595663.1425354.11834745902748968831@163.com> (raw)
In-Reply-To: <f7tse52x1zz.fsf@redhat.com>

Aaron, Ilya, thank you both for the review.

> There is an existing check for recursion in ovs_execute_actions() and in
> there we have a log before dropping:
> ...
> We should have a similar log here so we're not silently dropping.  But,
> since we now have two places where this check occurs (and it's
> complicated because of how deferred actions is processed), maybe it's
> better to have a function that does the management:

Good point.  v2 extracts the enter/exit logic into
ovs_exec_level_enter() and ovs_exec_level_exit() helpers, exactly as
you suggested, and uses them in both clone_execute() and
ovs_execute_actions().  The net_crit_ratelimited() log is now emitted
on every recursion-limit hit regardless of entry point.

> There is a different issue here though.  The exec_level is used as a
> counter for the flow keys during the clone.  And if we increment it
> unconditionally while not allocating new keys, we'll ran out of key
> slots much faster without actually using them.

Agreed this is a real concern.  As Aaron noted, most deployments nest
only once or twice so the practical pressure from this change should
be manageable, but decoupling the recursion counter from the key slot
index is the right long-term fix.  Happy to leave that as a follow-up
so this security fix stays focused.

v2 posted as a separate thread.

Regards,
yang zhuorao

  reply	other threads:[~2026-07-29  6:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  6:05 [PATCH net] net: openvswitch: fix stack exhaustion from unaccounted clone_execute() recursion yang zhuorao
2026-07-28 14:51 ` [net] " Aaron Conole
2026-07-28 15:03   ` Ilya Maximets
2026-07-28 21:01     ` Aaron Conole
2026-07-29  6:19       ` yang zhuorao [this message]
2026-07-29  9:56       ` Ilya Maximets

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=178530595663.1425354.11834745902748968831@163.com \
    --to=alexyoung0@163.com \
    --cc=aconole@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dev@openvswitch.org \
    --cc=echaudro@redhat.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=i.maximets@ovn.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=security@kernel.org \
    /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