On Thu, Feb 13, 2025 at 12:07:54PM +0800, Wentao Liang wrote:
In felix_update_tag_8021q_rx_rules(), the return value of ocelot_vcap_block_find_filter_by_id() is not checked, which could lead to a NULL pointer dereference if the filter is not found.
Add the necessary check and use `continue` to skip the current CPU port if the filter is not found, ensuring that all CPU ports are processed.
Fixes: f1288fd7293b ("net: dsa: felix: fix VLAN tag loss on CPU reception with ocelot-8021q") Cc: stable@vger.kernel.org # 6.11+ Signed-off-by: Wentao Liang vulab@iscas.ac.cn
drivers/net/dsa/ocelot/felix.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c index 3aa9c997018a..10ad43108b88 100644 --- a/drivers/net/dsa/ocelot/felix.c +++ b/drivers/net/dsa/ocelot/felix.c @@ -348,6 +348,8 @@ static int felix_update_tag_8021q_rx_rules(struct dsa_switch *ds, int port, outer_tagging_rule = ocelot_vcap_block_find_filter_by_id(block_vcap_es0, cookie, false);
if (!outer_tagging_rule)continue;felix_update_tag_8021q_rx_rule(outer_tagging_rule, vlan_filtering); -- 2.42.0.windows.2
Is this patch a result of static analysis or has a real problem been noticed? Could you make a more detailed analysis for me of the code path in which the filter cannot be found? because I'm not seeing it.
Hint: follow felix_change_tag_protocol(), and see which things are guaranteed to have succeeded if felix->tag_proto == DSA_TAG_PROTO_OCELOT_8021Q.
felix_tag_8021q_vlan_add() is called from dsa_tag_8021q_register(), and felix_tag_8021q_vlan_del() from dsa_tag_8021q_unregister().
felix_vlan_filtering() runs under rtnl_lock(), and so does felix_change_tag_protocol(). So felix_vlan_filtering() is always executed either entirely before, or entirely after felix_change_tag_protocol(), never concurrently.