From: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, Jamal Hadi Salim <jhs@mojatatu.com>,
Jiri Pirko <jiri@resnulli.us>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Simon Horman <horms@kernel.org>,
Henrik Steen <henrist@henrist.net>,
Olivier Tilmans <olivier.tilmans@nokia.com>,
Bob Briscoe <research@bobbriscoe.net>,
Olga Albisser <olga@albisser.org>,
GangMin Kim <km.kim1503@gmail.com>
Subject: Re: [PATCH net] net_sched: act_ct: drop all packets when not attached to ingress
Date: Tue, 17 Feb 2026 07:28:04 -0800 [thread overview]
Message-ID: <20260217072804.213307b9@kernel.org> (raw)
In-Reply-To: <674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com>
On Tue, 17 Feb 2026 10:38:52 +0100 Paolo Abeni wrote:
> Since the blamed commit below, classify can return TC_ACT_CONSUMED while
> the current skb being held by the defragmentation engine. As reported by
> GangMin Kim, if such packet is that may cause a UaF when the defrag engine
> later on tries to tuch again such packet.
>
> act_ct was never meant to be used outside of the ingress path. Making
> defrag really works for act_ct outside such constraints range from very
> difficult to completely impossible.
>
> Address the issue making act_ct drop any packet when not attached to the
> ingress path and additionally emit a warning about the bad
> configuration.
FWIW there is a test case in net/forwarding/tc_actions.sh that fails
now (needs to be adjusted/deleted/reconsidered).
--
pw-bot: cr
prev parent reply other threads:[~2026-02-17 15:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-17 9:38 [PATCH net] net_sched: act_ct: drop all packets when not attached to ingress Paolo Abeni
2026-02-17 10:42 ` Paolo Abeni
2026-02-17 14:49 ` Ilya Maximets
2026-02-17 15:52 ` Paolo Abeni
2026-02-17 19:37 ` Ilya Maximets
2026-02-18 14:28 ` Jamal Hadi Salim
2026-02-18 16:15 ` Ilya Maximets
2026-02-18 18:31 ` Jamal Hadi Salim
2026-02-18 18:44 ` Jamal Hadi Salim
2026-02-18 20:43 ` Paolo Abeni
2026-02-19 11:46 ` Ilya Maximets
2026-02-19 14:16 ` Jamal Hadi Salim
2026-02-19 20:13 ` Jamal Hadi Salim
2026-02-20 12:24 ` Victor Nogueira
2026-02-20 13:41 ` Ilya Maximets
2026-02-20 16:12 ` Victor Nogueira
2026-02-17 15:28 ` Jakub Kicinski [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=20260217072804.213307b9@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=henrist@henrist.net \
--cc=horms@kernel.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=km.kim1503@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olga@albisser.org \
--cc=olivier.tilmans@nokia.com \
--cc=pabeni@redhat.com \
--cc=research@bobbriscoe.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.