[PATCH v3] net/bnxt: fix flow create segfault

[Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>]

From: Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>

When creating a flow that requires a destination queue but none is
specified in the flow create command, find_matching_vnic() returns
NULL and the code falls through to insert the new filter into
vnic->filter, dereferencing the NULL vnic and causing a segfault.

Reject a flow create with no destination up front, right after
bnxt_validate_and_parse_flow() and before bnxt_match_filter() is
called (skipped for HWRM_CFA_TUNNEL_REDIRECT_FILTER, which has no
destination VNIC by design). Checking this only after
bnxt_match_filter() is not enough: when the new filter's pattern
matches an already-installed flow with a different destination,
bnxt_match_filter() unlinks that flow's old filter, links the new
(about-to-be-rejected) one in its place, frees the old filter, and
repoints the existing flow's flow->filter at the new one, all before
returning -EXDEV. Rejecting the missing-destination case afterward
then frees that same new filter while it is still linked into
vnic->filter and still referenced by the pre-existing flow, leaving
that unrelated flow's HW filter deleted and flow->filter pointing at
freed memory. Checking before bnxt_match_filter() ever runs avoids
triggering that mutation in the first place.

Fixes: 59119d49529e ("net/bnxt: fix flow create when RSS is disabled")
Cc: stable@dpdk.org

Signed-off-by: Dakota Sicher <dakota.sicher@broadcom.com>
Signed-off-by: Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>
---
v3:
* Moved the NULL-vnic check from right before the done: label (after
  the tunnel-redirect/EM/NTUPLE filter setup, where v2 had it) to
  right after bnxt_validate_and_parse_flow(), before
  bnxt_match_filter() runs. Stephen Hemminger found that checking
  only after bnxt_match_filter() has already run is not enough: for
  a flow that turns out to be an update (matches an existing flow's
  pattern with a different destination), bnxt_match_filter() has
  already unlinked the old filter, linked the new one in its place,
  freed the old one, and repointed the existing flow's flow->filter
  at the new one before returning -EXDEV -- rejecting afterward then
  frees that same new filter while it is still linked into
  vnic->filter and referenced by the pre-existing flow, corrupting
  that unrelated flow. Kishore Padmanabha separately flagged the old
  check's location as dead code once this move landed, since the
  earlier check already guarantees a match by the time execution
  reaches that point.
v2:
* Changed the NULL check from "if (!vnic)" to "if (vnic == NULL)" to
  match this file's established convention for pointer NULL checks.
* Kept RTE_FLOW_ERROR_TYPE_HANDLE rather than RTE_FLOW_ERROR_TYPE_ACTION
  as one reviewer suggested: every other rte_flow_error_set() call in
  this function uses RTE_FLOW_ERROR_TYPE_HANDLE regardless of the
  underlying cause.
* Fixed the new branch to reset ret = -EINVAL before goto free_filter,
  instead of leaving a stale update_flow-path -EXDEV to reach
  free_flow and report a misleading success-like error.

 drivers/net/bnxt/bnxt_flow.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
index 4bf38043b5..62dbb028f0 100644
--- a/drivers/net/bnxt/bnxt_flow.c
+++ b/drivers/net/bnxt/bnxt_flow.c
@@ -2047,6 +2047,16 @@ bnxt_flow_create(struct rte_eth_dev *dev,
 	if (ret != 0)
 		goto free_filter;
 
+	if (filter->filter_type != HWRM_CFA_TUNNEL_REDIRECT_FILTER &&
+	    find_matching_vnic(bp, filter) == NULL) {
+		rte_flow_error_set(error, EINVAL,
+				   RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
+				   "Missing destination action for flow.");
+		bnxt_hwrm_clear_l2_filter(bp, filter);
+		ret = -EINVAL;
+		goto free_filter;
+	}
+
 	ret = bnxt_match_filter(bp, filter);
 	if (ret == -EEXIST) {
 		PMD_DRV_LOG_LINE(DEBUG, "Flow already exists.");
-- 
2.47.3