CVE-2026-98881 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()
This rcu_barrier() came from a time call_rcu() calls were used in net/bridge/br_multicast.c.
Now kfree_rcu() is there, we can remove this problematic rcu_barrier() which causes extreme RTNL pressure in many syzbot reports.
INFO: task syz-executor:77945 is blocked on a mutex likely owned by task kworker/u1024:5:36537. task:kworker/u1024:5 state:D stack:24616 pid:36537 tgid:36537 ppid:2 task_flags:0x4208060 flags:0x00080000 last_sleep:612797637337 Workqueue: netns cleanup_net Call Trace: <TASK> [<ffffffff81914eaa>] context_switch+0xf2a/0x1730 kernel/sched/core.c:6483
[<ffffffff81201143>] __schedule+0x1133/0x43a0 kernel/sched/core.c:8411
[<ffffffff8120446b>] __schedule_loop kernel/sched/core.c:8514 [inline]
[<ffffffff8120446b>] schedule+0xab/0x260 kernel/sched/core.c:8529
[<ffffffff8121a093>] schedule_timeout+0xc3/0x2b0 kernel/time/sleep_timeout.c:75
[<ffffffff81205347>] do_wait_for_common kernel/sched/completion.c:100 [inline]
[<ffffffff81205347>] __wait_for_common kernel/sched/completion.c:121 [inline]
[<ffffffff81205347>] wait_for_common kernel/sched/completion.c:132 [inline]
[<ffffffff81205347>] wait_for_completion+0x2c7/0x5d0 kernel/sched/completion.c:153
[<ffffffff81b8f27f>] rcu_barrier+0x49f/0x620 kernel/rcu/tree.c:3888
[<ffffffff860091b3>] br_multicast_dev_del+0x303/0x350 net/bridge/br_multicast.c:4459
[<ffffffff85fb5dbc>] br_dev_uninit+0x1c/0x40 net/bridge/br_device.c:157
[<ffffffff8568058c>] unregister_netdevice_many_notify+0x1c1c/0x2300 net/core/dev.c:12599
[<ffffffff8562be43>] ops_exit_rtnl_list net/core/net_namespace.c:187 [inline]
[<ffffffff8562be43>] ops_undo_list+0x3d3/0x940 net/core/net_namespace.c:248
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel vulnerability addressed in this update involves a performance and stability issue within the network bridge subsystem, specifically located in the br_multicast_dev_del function. The root cause of the flaw is an unnecessary invocation of rcu_barrier() during device deletion operations for multicast groups. This call originated from legacy code where kfree_rcu was not yet available or used, requiring explicit synchronization to ensure that all prior RCU read-side critical sections had completed before freeing memory. However, with the modern adoption of kfree_rcu in net/bridge/br_multicast.c, which handles deferred free operations safely without blocking execution until all grace periods are complete, the explicit rcu_barrier() call has become redundant and counterproductive.
The operational impact of this stale synchronization primitive is severe, manifesting as extreme RTNL (Routing Netlink) pressure and significant system latency. When a network namespace or bridge device is being cleaned up, particularly in automated testing environments like syzbot, the kernel enters a state where tasks are blocked waiting for mutexes held by worker threads that are themselves stalled due to the rcu_barrier() call. The barrier forces the calling thread to wait synchronously for all previously queued RCU callbacks to finish executing across all CPUs. In high-throughput or frequently changing network configurations, this creates a bottleneck that can lead to task blocking states, as evidenced by syzbot reports showing tasks stuck in uninterruptible sleep while waiting for completions related to rcu_barrier(). This not only degrades system performance but also increases the risk of deadlocks and resource exhaustion under load.
From a technical perspective, this issue aligns with CWE-400: Uncontrolled Resource Consumption, as the unnecessary synchronization causes excessive CPU time and lock contention without providing additional safety benefits in the current codebase context. The ATT&CK framework does not directly map to kernel internal performance bugs of this nature, but the resulting denial-of-service conditions through resource exhaustion can be loosely associated with T1496: Resource Hijacking if exploited by an attacker to degrade system availability. However, primarily this is a stability and efficiency flaw rather than a direct security exploit vector for privilege escalation or data leakage. The fix involves removing the rcu_barrier() call entirely, relying on the inherent safety of kfree_rcu which guarantees that memory will not be freed until all readers have exited their critical sections without requiring explicit barriers in every deletion path.
Mitigation strategies primarily involve applying the kernel patch that removes this specific line of code from br_multicast_dev_del(). For systems unable to immediately update, administrators should minimize frequent creation and destruction of network bridges or multicast groups where possible to reduce exposure to the latency spike. Monitoring for high CPU usage during network namespace teardowns can help identify affected environments. The long-term resolution is strictly dependent on updating the Linux kernel to a version that includes this fix, ensuring that the bridge subsystem utilizes modern RCU primitives correctly without legacy synchronization overheads.