[PATCH net] octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()

Dan Carpenter posted 1 patch 1 week, 1 day ago
drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH net] octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
Posted by Dan Carpenter 1 week, 1 day ago
This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
and then dereferences it on the next line.  Two lines later, we take
a mutex so I don't think this is an RCU safe region.  Re-order it to do
the dereferences before queuing up the free.

Fixes: 68fbff68dbea ("octeontx2-pf: Add police action for TC flower")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
index 5f80b23c5335..26a08d2cfbb1 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
@@ -1326,7 +1326,6 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
 
 free_leaf:
 	otx2_tc_del_from_flow_list(flow_cfg, new_node);
-	kfree_rcu(new_node, rcu);
 	if (new_node->is_act_police) {
 		mutex_lock(&nic->mbox.lock);
 
@@ -1346,6 +1345,7 @@ static int otx2_tc_add_flow(struct otx2_nic *nic,
 
 		mutex_unlock(&nic->mbox.lock);
 	}
+	kfree_rcu(new_node, rcu);
 
 	return rc;
 }
-- 
2.51.0
Re: [PATCH net] octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
Posted by Vadim Fedorenko 1 week, 1 day ago
On 23/09/2025 12:19, Dan Carpenter wrote:
> This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
> and then dereferences it on the next line.  Two lines later, we take
> a mutex so I don't think this is an RCU safe region.  Re-order it to do
> the dereferences before queuing up the free.
> 
> Fixes: 68fbff68dbea ("octeontx2-pf: Add police action for TC flower")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>