[PATCH] net/mlx5: fix crash when using meter in transfer flow

[PATCH] net/mlx5: fix crash when using meter in transfer flow

[Khadem Ullah]

When creating a flow rule with the transfer attribute and a meter action,
the driver did not validate this combination and would crash due to
unsupported handling.

This patch adds explicit validation rejecting meter action in transfer
flows with an appropriate error message.

Fixes: 46a5e6bc6a85 ("net/mlx5: prepare meter flow tables")
Cc: stable@dpdk.org

Steps to reproduce:
1. Launch testpmd:
   ./build/app/dpdk-testpmd -l 0,1 -a <PCI BDF> -- -i --rxq=8 --txq=8

2. Inside testpmd:
   add port meter profile trtcm_rfc2698 0 0 5 10 50 100 1
   add port meter policy 0 0 g_actions mark id 3 / queue index 2 / end /
      y_actions mark id 7 / queue index 3 / end r_actions drop / end
   create port meter 0 0 0 0 yes 0xffff 0 y 0
3. flow create 0 group 0 ingress pattern eth / ipv4 / end actions
     jump group 1 / end
3. Following causes a segmentation fault:
   flow create 0 transfer ingress pattern eth / ipv4 /
      end actions meter mtr_id 0 / end

This patch ensures proper handling of the meter action with
transfer rule to prevent this crash.

Signed-off-by: Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk>
---
 drivers/net/mlx5/mlx5_flow.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 8db372123c..a7b793ef29 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -7993,7 +7993,17 @@ mlx5_flow_create(struct rte_eth_dev *dev,
 	struct rte_flow_attr *new_attr = (void *)(uintptr_t)attr;
 	uint32_t prio = attr->priority;
 	uintptr_t flow_idx;
-
+	if (attr && attr->transfer) {
+		const struct rte_flow_action *act;
+		for (act = actions; act && act->type != RTE_FLOW_ACTION_TYPE_END; ++act) {
+			if (act->type == RTE_FLOW_ACTION_TYPE_METER) {
+				rte_flow_error_set(error, ENOTSUP,
+					RTE_FLOW_ERROR_TYPE_ACTION, act,
+					"Meter action is not supported in transfer flows");
+				return NULL;
+			}
+		}
+	}
 	/*
 	 * If the device is not started yet, it is not allowed to created a
 	 * flow from application. PMD default flows and traffic control flows
-- 
2.43.0

Re: [PATCH] net/mlx5: fix crash when using meter in transfer flow

[Dariusz Sosnowski]

+ mlx5 maintainers

Thank you for the patch.

On Wed, Jul 02, 2025 at 08:36:17AM -0400, Khadem Ullah wrote:
> When creating a flow rule with the transfer attribute and a meter action,
> the driver did not validate this combination and would crash due to
> unsupported handling.
> 
> This patch adds explicit validation rejecting meter action in transfer
> flows with an appropriate error message.
> 
> Fixes: 46a5e6bc6a85 ("net/mlx5: prepare meter flow tables")
> Cc: stable@dpdk.org
> 
> Steps to reproduce:
> 1. Launch testpmd:
>    ./build/app/dpdk-testpmd -l 0,1 -a <PCI BDF> -- -i --rxq=8 --txq=8
> 
> 2. Inside testpmd:
>    add port meter profile trtcm_rfc2698 0 0 5 10 50 100 1
>    add port meter policy 0 0 g_actions mark id 3 / queue index 2 / end /
>       y_actions mark id 7 / queue index 3 / end r_actions drop / end
>    create port meter 0 0 0 0 yes 0xffff 0 y 0
> 3. flow create 0 group 0 ingress pattern eth / ipv4 / end actions
>      jump group 1 / end
> 3. Following causes a segmentation fault:
>    flow create 0 transfer ingress pattern eth / ipv4 /
>       end actions meter mtr_id 0 / end

I tried these steps on v25.07-rc3 and the segfault does not reproduce for me.
rte_flow_create() correctly returns ENOTSUP for that case.

Similar case was segfaulting recently,
but it was fixed by this commit: https://github.com/DPDK/dpdk/commit/c30b356a4d48542fe99c47aa470afc8cd1ced9f5
This specific fix is available from v25.03 and is included in v24.11.2

On other LTSes - v22.11.8 and v23.11.4 - segfault does not reproduce
for me as well. Either ENOTSUP or validation error is reported.

Which DPDK version are you using?

I see that the flow rule is created with transfer attribute.
Are you using a setup with switchdev enabled?
(https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.html)

> 
> This patch ensures proper handling of the meter action with
> transfer rule to prevent this crash.
> 
> Signed-off-by: Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk>
> ---
>  drivers/net/mlx5/mlx5_flow.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index 8db372123c..a7b793ef29 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -7993,7 +7993,17 @@ mlx5_flow_create(struct rte_eth_dev *dev,
>  	struct rte_flow_attr *new_attr = (void *)(uintptr_t)attr;
>  	uint32_t prio = attr->priority;
>  	uintptr_t flow_idx;
> -
> +	if (attr && attr->transfer) {
> +		const struct rte_flow_action *act;
> +		for (act = actions; act && act->type != RTE_FLOW_ACTION_TYPE_END; ++act) {
> +			if (act->type == RTE_FLOW_ACTION_TYPE_METER) {
> +				rte_flow_error_set(error, ENOTSUP,
> +					RTE_FLOW_ERROR_TYPE_ACTION, act,
> +					"Meter action is not supported in transfer flows");
> +				return NULL;
> +			}
> +		}
> +	}
>  	/*
>  	 * If the device is not started yet, it is not allowed to created a
>  	 * flow from application. PMD default flows and traffic control flows
> -- 
> 2.43.0
> 

Best regards,
Dariusz Sosnowski

Re: [PATCH] net/mlx5: fix crash when using meter in transfer flow

[Dariusz Sosnowski]

On Tue, Jul 15, 2025 at 07:39:53PM +0200, Dariusz Sosnowski wrote:
> + mlx5 maintainers
> 
> Thank you for the patch.
> 
> On Wed, Jul 02, 2025 at 08:36:17AM -0400, Khadem Ullah wrote:
> > When creating a flow rule with the transfer attribute and a meter action,
> > the driver did not validate this combination and would crash due to
> > unsupported handling.
> > 
> > This patch adds explicit validation rejecting meter action in transfer
> > flows with an appropriate error message.
> > 
> > Fixes: 46a5e6bc6a85 ("net/mlx5: prepare meter flow tables")
> > Cc: stable@dpdk.org
> > 
> > Steps to reproduce:
> > 1. Launch testpmd:
> >    ./build/app/dpdk-testpmd -l 0,1 -a <PCI BDF> -- -i --rxq=8 --txq=8
> > 
> > 2. Inside testpmd:
> >    add port meter profile trtcm_rfc2698 0 0 5 10 50 100 1
> >    add port meter policy 0 0 g_actions mark id 3 / queue index 2 / end /
> >       y_actions mark id 7 / queue index 3 / end r_actions drop / end
> >    create port meter 0 0 0 0 yes 0xffff 0 y 0
> > 3. flow create 0 group 0 ingress pattern eth / ipv4 / end actions
> >      jump group 1 / end
> > 3. Following causes a segmentation fault:
> >    flow create 0 transfer ingress pattern eth / ipv4 /
> >       end actions meter mtr_id 0 / end
> 
> I tried these steps on v25.07-rc3 and the segfault does not reproduce for me.
> rte_flow_create() correctly returns ENOTSUP for that case.
> 
> Similar case was segfaulting recently,
> but it was fixed by this commit: https://github.com/DPDK/dpdk/commit/c30b356a4d48542fe99c47aa470afc8cd1ced9f5
> This specific fix is available from v25.03 and is included in v24.11.2
> 
> On other LTSes - v22.11.8 and v23.11.4 - segfault does not reproduce
> for me as well. Either ENOTSUP or validation error is reported.
> 
> Which DPDK version are you using?
> 
> I see that the flow rule is created with transfer attribute.
> Are you using a setup with switchdev enabled?
> (https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.html)
> 

Also, for wider context:

- If switchdev is not enabled, then creating transfer flow
  rules is not allowed.
  Without switchdev enabled, mlx5 PMD cannot control
  the embedded switch of the NIC, so no transfer flow rules can be created.
  This is the reason for current behavior of returning ENOTSUP on main branch.

- If switchdev is enabled, transfer flow rules are allowed.
  There are however 2 important points:

  - Transfer attribute cannot be mixed with either ingress or egress.
    (https://doc.dpdk.org/guides/prog_guide/ethdev/flow_offload.html#attribute-transfer)
  - In default configuration, mlx5 PMD does not support QUEUE actions for transfer flow rules.
    In the steps above, meter policy contains QUEUE actions, so using
    such meter in transfer rules is not allowed and is rejected by the driver.

Re: [PATCH] net/mlx5: fix crash when using meter in transfer flow

[Khadem Ullah]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=yes, Size: 783 bytes --]

Hi Dariusz,

Yes, you are right — I believe this has been fixed since DPDK v24.11 by the commit you mentioned:
https://github.com/DPDK/dpdk/commit/c30b356a4d48542fe99c47aa470afc8cd1ced9f5

Previously, this appeared to be an edge case where a segfault was triggered when a transfer rule was created (even when not using switchdev). But as confirmed, recent versions (v24.11.2 and newer) now correctly return ENOTSUP or a validation error instead of crashing.

I understand that transfer rules are only valid in switchdev mode, and that using them outside that context is unsupported. I encountered the segfault when testing this specific combination, but it seems the issue has been properly addressed now in the latest versions.

Thanks for confirming!

Best regards,
Khadem Ullah

Re: [PATCH] net/mlx5: fix crash when using meter in transfer flow

[Dariusz Sosnowski]

On Wed, Jul 16, 2025 at 03:23:19AM -0400, Khadem Ullah wrote:
> Hi Dariusz,
> 
> Yes, you are right — I believe this has been fixed since DPDK v24.11 by the commit you mentioned:
> https://github.com/DPDK/dpdk/commit/c30b356a4d48542fe99c47aa470afc8cd1ced9f5
> 
> Previously, this appeared to be an edge case where a segfault was triggered when a transfer rule was created (even when not using switchdev). But as confirmed, recent versions (v24.11.2 and newer) now correctly return ENOTSUP or a validation error instead of crashing.
> 
> I understand that transfer rules are only valid in switchdev mode, and that using them outside that context is unsupported. I encountered the segfault when testing this specific combination, but it seems the issue has been properly addressed now in the latest versions.
> 
> Thanks for confirming!
> 
> Best regards,
> Khadem Ullah

No problem, happy to help.

Best regards,
Dariusz Sosnowski