In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: don't…

Why it is Yellow

• CVSS 7.8 high
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/5a3f7a683aee56e1f15c9d53041f3236767eaae7
• https://git.kernel.org/stable/c/8243d587a081e790ad96e80d48eef44d9f7ef005
• https://git.kernel.org/stable/c/b45e8c24608c992d1e2cea047eb5bcbfa537f86b
• https://git.kernel.org/stable/c/025c25ad73323c7dc5af4ee97fe0a2c0b3c177c8
• https://git.kernel.org/stable/c/ab836d56ff43f2e7927e88c83cd02c47a98a672e
• https://git.kernel.org/stable/c/b0db9f4ff402becff710ab27dbd9f6fe4850b47e
• https://git.kernel.org/stable/c/be331b23c650de9518f8266b901d8abb9b36af77
• https://git.kernel.org/stable/c/e69d4927dacd6ddaff09777a89efc0d3143d3b0d

Original description

In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: don't truncate the port group walk on teardown __br_multicast_disable_port_ctx() and br_multicast_del_port() walk port->mglist with hlist_for_each_entry_safe(). However, br_multicast_find_del_pg() can also delete other entries from the same list through br_multicast_fwd_src_remove() or __fwd_del_star_excl(). If such an entry is the iterator's saved next node, hlist_del_init() clears its ->next and terminates the walk early. The reproducer triggers this in both teardown walks, leaving port groups in the bridge mdb with a dangling ->key.port after del_nbp() frees the port: BUG: KASAN: slab-use-after-free in __mdb_fill_info+0x1191/0x1320 __mdb_fill_info+0x1191/0x1320 br_mdb_dump+0x594/0xe40 rtnl_mdb_dump+0x1cf/0x5d0 Use hlist_del_init_rcu() to unlink the group while preserving ->next. br_multicast_del_pg() and the teardown walks run under br->multicast_lock. The GC worker must acquire the same lock before detaching the group for destruction, so the node remains alive while the walk uses the preserved pointer. Preserving ->next means a walk can now reach a group that an earlier iteration already deleted as a side effect. That group is off mp->ports, so br_multicast_find_del_pg() would fall through its port scan and hit the trailing WARN_ON(1). Skip such groups at the top of that helper: a port group is put on port->mglist when it is created and only unlinked when it is deleted, so hlist_unhashed() identifies exactly this case.