<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 07:44:43 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-49338 — net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2022-49338</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules&lt;/p&gt;
&lt;p&gt;CT cleanup assumes that all tc rules were deleted first, and so
is free to delete the CT shared resources (e.g the dr_action
fwd_action which is shared for all tuples). But currently for
uplink, this is happens in reverse, causing the below trace.&lt;/p&gt;
&lt;p&gt;CT cleanup is called from:
mlx5e_cleanup_rep_tx()-&amp;gt;mlx5e_cleanup_uplink_rep_tx()-&amp;gt;
mlx5e_rep_tc_cleanup()-&amp;gt;mlx5e_tc_esw_cleanup()-&amp;gt;
mlx5_tc_ct_clean()&lt;/p&gt;
&lt;p&gt;Only afterwards, tc cleanup is called from:
mlx5e_cleanup_rep_tx()-&amp;gt;mlx5e_tc_ht_cleanup()
which would have deleted all the tc ct rules, and so delete
all the offloaded tuples.&lt;/p&gt;
&lt;p&gt;Fix this reversing the order of init and on cleanup, which
will result in tc cleanup then ct cleanup.&lt;/p&gt;
&lt;p&gt;[ 9443.593347] WARNING: CPU: 2 PID: 206774 at drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1882 mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]
[ 9443.593349] Modules linked in: act_ct nf_flow_table rdma_ucm(O) rdma_cm(O) iw_cm(O) ib_ipoib(O) ib_cm(O) ib_umad(O) mlx5_core(O-) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) psample ib_core(O) mlx_compat(O) ip_gre gre ip_tunnel act_vlan bonding geneve esp6_offload esp6 esp4_offload esp4 act_tunnel_key vxlan ip6_udp_tunnel udp_tunnel act_mirred act_skbedit act_gact cls_flower sch_ingress nfnetlink_cttimeout nfnetlink xfrm_user xfrm_algo 8021q garp stp ipmi_devintf mrp ipmi_msghandler llc openvswitch nsh nf_conncount n…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules&lt;/p&gt;
&lt;p&gt;CT cleanup assumes that all tc rules were deleted first, and so
is free to delete the CT shared resources (e.g the dr_action
fwd_action which is shared for all tuples). But currently for
uplink, this is happens in reverse, causing the below trace.&lt;/p&gt;
&lt;p&gt;CT cleanup is called from:
mlx5e_cleanup_rep_tx()-&amp;gt;mlx5e_cleanup_uplink_rep_tx()-&amp;gt;
mlx5e_rep_tc_cleanup()-&amp;gt;mlx5e_tc_esw_cleanup()-&amp;gt;
mlx5_tc_ct_clean()&lt;/p&gt;
&lt;p&gt;Only afterwards, tc cleanup is called from:
mlx5e_cleanup_rep_tx()-&amp;gt;mlx5e_tc_ht_cleanup()
which would have deleted all the tc ct rules, and so delete
all the offloaded tuples.&lt;/p&gt;
&lt;p&gt;Fix this reversing the order of init and on cleanup, which
will result in tc cleanup then ct cleanup.&lt;/p&gt;
&lt;p&gt;[ 9443.593347] WARNING: CPU: 2 PID: 206774 at drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1882 mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]
[ 9443.593349] Modules linked in: act_ct nf_flow_table rdma_ucm(O) rdma_cm(O) iw_cm(O) ib_ipoib(O) ib_cm(O) ib_umad(O) mlx5_core(O-) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) psample ib_core(O) mlx_compat(O) ip_gre gre ip_tunnel act_vlan bonding geneve esp6_offload esp6 esp4_offload esp4 act_tunnel_key vxlan ip6_udp_tunnel udp_tunnel act_mirred act_skbedit act_gact cls_flower sch_ingress nfnetlink_cttimeout nfnetlink xfrm_user xfrm_algo 8021q garp stp ipmi_devintf mrp ipmi_msghandler llc openvswitch nsh nf_conncount n…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2022-49338</guid>
    </item>
  </channel>
</rss>
