On 11/09/2026 13:06, Nikolay Aleksandrov wrote:
__vlan_flush() is used for both port and bridge VLAN groups. The error
path unconditionally dereferences the port argument even though
br_vlan_flush() calls it with a NULL port. Any error (e.g. switchdev) while
deleting a bridge VLAN can result in a NULL pointer dereference.
Use a bridge-specific error message when called for the bridge device.

Fixes: 5454f5c28eca ("net: bridge: vlan: check for errors from __vlan_del in 
__vlan_flush")
Signed-off-by: Nikolay Aleksandrov <[email protected]>
---
  net/bridge/br_vlan.c | 13 +++++++++----
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 1748ea1fc202..3aa0e1fedeb2 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -467,10 +467,15 @@ static void __vlan_flush(const struct net_bridge *br,
                vid = vlan->vid;
                err = __vlan_del(vlan, true);
                if (err) {
-                       br_err(br,
-                              "port %u(%s) failed to delete vlan %d: %pe\n",
-                              (unsigned int) p->port_no, p->dev->name,
-                              vid, ERR_PTR(err));
+                       if (p)
+                               br_err(br,
+                                      "port %u(%s) failed to delete vlan %d: 
%pe\n",
+                                      (unsigned int)p->port_no, p->dev->name,
+                                      vid, ERR_PTR(err));
+                       else
+                               br_err(br,
+                                      "failed to delete bridge vlan %d: %pe\n",
+                                      vid, ERR_PTR(err));
                }
        }

Note that currently only switchdev can err out and on the br_vlan_flush() path 
that
is unlikely because all ports have already been removed. But that relies only on
the facts that no swdev driver will return an error at that time and that 
__vlan_del
returns an error only from swdev (currently), these are not hard contracts or 
APIs
anyone follows, it is by mere chance that we haven't hit it. It would be best 
to handle
the br/port cases separately as usual and check the port pointer before 
dereferencing.
I think this belongs with the previous fix for the memory leaks.

Cheers,
 Nik

Reply via email to