Cloudanix VulnDB

CVE-2026-99117

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel's network bridging code can cause systems to crash when multicast groups are cleaned up during port removal.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux kernel bridge multicast teardown walks (__br_multicast_disable_port_ctx, br_multicast_del_port) where br_multicast_find_del_pg side-effect deletions via hlist_del_init invalidate the iterator's next pointer, allowing access to freed port groups in __mdb_fill_info during br_mdb_dump.

Why it matters to the business

Linux systems using bridge multicast can experience kernel crashes or instability during port teardown or MDB dumps, leading to network disruption and potential denial of service until patched.

How an attack unfolds

An attacker configures bridge multicast groups and triggers port deletion sequences that cause concurrent list modifications during teardown walks under multicast_lock, resulting in a dangling pointer dereference when br_mdb_dump later accesses the freed structure.

How to fix it

Apply the upstream kernel fix that replaces hlist_del_init with hlist_del_init_rcu, adds hlist_unhashed checks in br_multicast_find_del_pg, and ensures GC workers respect br->multicast_lock; rebuild and reboot to the corrected kernel version.

How to confirm the fix worked

Confirm the patched kernel source contains the hlist_del_init_rcu change and hlist_unhashed guard; reproduce teardown scenarios under KASAN and verify absence of slab-use-after-free reports in __mdb_fill_info.

Typical attack path

  1. Configure bridge with multicast groups and ports
  2. Trigger port deletion or multicast disable via netlink or interface teardown
  3. Induce side-effect deletions from br_multicast_fwd_src_remove during the hlist walk
  4. Force br_mdb_dump to traverse the corrupted mglist and hit the freed entry

How to detect it

Search kernel logs and dmesg for KASAN slab-use-after-free reports referencing __mdb_fill_info, br_mdb_dump, or br_multicast_del_port during bridge teardown events.

  • BUG: KASAN: slab-use-after-free in __mdb_fill_info
  • __mdb_fill_info+0x1191/0x1320
  • br_mdb_dump+0x594/0xe40
  • hlist_for_each_entry_safe.*mglist

What your security team should do

  • Prioritize kernel updates for bridge-enabled systems within the next maintenance window
  • Enable KASAN or similar memory debugging in test environments to validate the fix
  • Monitor netlink and bridge multicast configuration logs for unusual teardown activity

The record

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.

Affected packages

Ecosystem Package Introduced Fixed