[PATCH AUTOSEL 6.18-6.6] bridge: Add missing READ_ONCE() annotations around FDB destination port

[PATCH AUTOSEL 6.18-6.6] bridge: Add missing READ_ONCE() annotations around FDB destination port

[Sasha Levin]

From: Ido Schimmel <idosch@nvidia.com>

[ Upstream commit bcdfd9fb109e0c9d76c345b2346b6b75ed1f476d ]

When roaming, the FDB destination port can change without holding the
bridge's hash lock. Therefore, add missing READ_ONCE() annotations in
both RCU readers and readers that hold the lock. In the latter case, the
annotation is not needed in places where the FDB entry was already
validated to be a local entry since such entries cannot roam.

Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260517115009.175163-1-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `bridge: Add missing READ_ONCE() annotations
around FDB destination port`

**Local tree:** `v6.18.44` (Makefile: 6.18.44)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1 — Subject line**

Record: `[bridge]` `[add]` missing `READ_ONCE()` annotations around FDB
destination port during concurrent roaming updates.

**Step 1.2 — Tags**

Record:
- `Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>` — bridge
  maintainer ack
- `Signed-off-by: Ido Schimmel <idosch@nvidia.com>` — bridge
  maintainer/author
- `Signed-off-by: Jakub Kicinski <kuba@kernel.org>` — networking tree
  maintainer
- `Link:
  https://patch.msgid.link/20260517115009.175163-1-idosch@nvidia.com`
- No `Fixes:`, `Reported-by:`, `Cc: stable@vger.kernel.org`, `Tested-
  by:`, or syzbot tags

**Step 1.3 — Body analysis**

Record:
- **Bug:** `fdb->dst` can change during MAC roaming without holding
  `br->hash_lock`.
- **Symptom:** Readers can observe a changing destination port; without
  `READ_ONCE()`, loads are not paired with existing `WRITE_ONCE()`
  writers and may be inconsistent across a read/use sequence.
- **Root cause:** `br_fdb_update()` updates `fdb->dst` locklessly on the
  fast path (`WRITE_ONCE(fdb->dst, source)` at line 1030 in `br_fdb.c`),
  while several readers still used plain `f->dst` / `dst->dst` loads.
- **Version info:** None in the message.

**Step 1.4 — Hidden bug fix?**

Record: **Yes.** Although labeled as annotation work, this is a real
concurrency correctness fix in the bridge forwarding and FDB management
paths, completing an established `READ_ONCE`/`WRITE_ONCE` pattern for
`fdb->dst`.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1 — Inventory**

Record:
- `net/bridge/br_device.c`: 1 line changed (`br_dev_xmit`)
- `net/bridge/br_input.c`: 1 line changed (`br_handle_frame_finish`)
- `net/bridge/br_fdb.c`: 4 lines changed across 3 functions
- **Total:** ~6 functional lines, 3 files, surgical scope
- **Functions modified:** `br_dev_xmit`, `br_handle_frame_finish`,
  `br_fdb_changeaddr`, `br_fdb_delete_by_port`, `br_fdb_clear_offload`

**Step 2.2 — Code flow changes**

Record:
| Location | Before | After |
|---|---|---|
| `br_dev_xmit` | `br_forward(dst->dst, ...)` after RCU FDB lookup |
`br_forward(READ_ONCE(dst->dst), ...)` — single stable snapshot of
roaming port |
| `br_handle_frame_finish` | same pattern on receive/forward path | same
fix |
| `br_fdb_changeaddr` | `f->dst == p` under `hash_lock` |
`READ_ONCE(f->dst) == p` |
| `br_fdb_delete_by_port` | `f->dst != p` under `hash_lock` |
`READ_ONCE(f->dst) != p` |
| `br_fdb_clear_offload` | `f->dst == p` under `hash_lock` |
`READ_ONCE(f->dst) == p` |

**Step 2.3 — Bug mechanism**

Record: **Race condition / data-race correctness fix.** Category (b)
synchronization. `br_fdb_update()` changes `fdb->dst` without
`hash_lock`:

```1026:1031:net/bridge/br_fdb.c
                        /* fastpath: update of existing entry */
                        if (unlikely(source != READ_ONCE(fdb->dst) &&
                                     !test_bit(BR_FDB_STICKY,
&fdb->flags))) {
                                br_switchdev_fdb_notify(br, fdb,
RTM_DELNEIGH);
                                WRITE_ONCE(fdb->dst, source);
```

Readers on hot forwarding paths and FDB iterators could observe a
changing `dst` pointer. `br_forward()` handles `NULL` (`if
(unlikely(!to))`), but a stale non-NULL port causes mis-forwarding
during roam; FDB iterators can miss or mishandle entries during
concurrent updates.

**Step 2.4 — Fix quality**

Record: **High quality, minimal, obviously correct.** Matches the
existing subsystem convention from `3e19ae7c6fd62` and follow-up
`5424e678f9b30`. Regression risk is very low — only adds documented
single-load snapshots.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1 — Blame**

Record:
- `br_device.c:110` and `br_input.c:226`: original code from 2016
  (Nikolay Aleksandrov), predating `READ_ONCE` annotations
- `br_fdb.c:473`: from 2019, also predating full annotation coverage
- Buggy plain loads have been present since before `3e19ae7c6fd62`
  (2021)

**Step 3.2 — Fixes: tag**

Record: Not applicable — no `Fixes:` tag.

**Step 3.3 — Related file history**

Record:
- `3e19ae7c6fd62` — introduced `READ_ONCE`/`WRITE_ONCE` for `fdb->dst`
  broadly (in tree)
- `5424e678f9b30` — “use a stable FDB dst snapshot in RCU readers”;
  fixed `br_fdb_fillbuf`, `fdb_delete_local` writers, etc.; `Cc:
  stable@vger.kernel.org` (in tree)
- `17071fb5cb9c2` — annotated `fdb->{updated,used}` races (in tree)
- This commit fills remaining gaps after those fixes
- **Standalone:** yes, no series dependency

**Step 3.4 — Author context**

Record: Ido Schimmel is an active bridge maintainer (`Reviewed-by` on
related stable-bound fix `5424e678`). Nikolay Aleksandrov acked.

**Step 3.5 — Prerequisites**

Record:
- Requires `WRITE_ONCE(fdb->dst, ...)` writers — present since
  `3e19ae7c6fd62`
- Requires roaming fast path in `br_fdb_update()` — present
- No additional commits required; patch dry-run applies cleanly

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1 — Original discussion**

Record: **UNVERIFIED** — `b4 dig -c <commit>` could not be run (commit
not present locally); lore.kernel.org and patch.msgid.link blocked by
bot protection (Anubis).

**Step 4.2 — Reviewers**

Record: **UNVERIFIED** via `b4 dig -w`. Commit message shows maintainer
ack from Nikolay Aleksandrov and merge by Jakub Kicinski.

**Step 4.3 — Bug report**

Record: Not applicable — no `Reported-by:` or syzbot link.

**Step 4.4 — Related patches**

Record: Part of ongoing `fdb->dst` concurrency hardening; directly
complements in-tree `5424e678f9b30`.

**Step 4.5 — Stable list history**

Record: **UNVERIFIED** — lore stable search inaccessible.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1 — Key functions**

Record: `br_dev_xmit`, `br_handle_frame_finish`, `br_fdb_changeaddr`,
`br_fdb_delete_by_port`, `br_fdb_clear_offload`

**Step 5.2 — Callers / reachability**

Record:
- `br_dev_xmit` — bridge device transmit hot path (every locally
  originated unicast frame)
- `br_handle_frame_finish` — bridge receive/forward hot path (every
  forwarded unicast frame)
- `br_fdb_delete_by_port` — port removal/teardown
- `br_fdb_changeaddr` — MAC address change on port
- `br_fdb_clear_offload` — switchdev offload cleanup

All are reachable in normal bridge operation; forwarding paths are among
the hottest networking code paths.

**Step 5.3 — Callees**

Record: `br_forward()` dereferences port and forwards skb;
`br_fdb_find_rcu()` provides RCU-protected FDB entry; concurrent writer
is `br_fdb_update()`.

**Step 5.4 — User triggerability**

Record: **Yes.** Any bridge with learned MACs that roam between ports
triggers `br_fdb_update()` lockless `fdb->dst` changes while packets are
being forwarded.

**Step 5.5 — Similar patterns**

Record: Most other `fdb->dst` readers in this tree already use
`READ_ONCE()` — e.g. `br_fdb_fillbuf`, `br_fdb_test_addr`,
`br_switchdev_fdb_notify`, `br_arp_nd_proxy.c`. The patched sites are
the remaining outliers.

---

## PHASE 6: CROSS-REFERENCE AGAINST LOCAL TREE (v6.18.44)

**Step 6.1 — Buggy code present?**

Record: **Yes.** Verified missing annotations at:
- `br_device.c:110`: `br_forward(dst->dst, ...)`
- `br_input.c:226`: `br_forward(dst->dst, ...)`
- `br_fdb.c:473`, `881`, `1663`: plain `f->dst` comparisons

Roaming writer path is present (`br_fdb.c:1030`).

**Step 6.2 — Backport difficulty**

Record: **Clean apply** — `patch --dry-run` succeeded with no conflicts.

**Step 6.3 — Related fixes already present?**

Record: Partial fix `5424e678f9b30` is already in this tree; this commit
is the remaining coverage, not a duplicate.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1 — Subsystem / criticality**

Record: `net/bridge` — **IMPORTANT** (widely deployed in servers, VMs,
containers, embedded networking).

**Step 7.2 — Activity**

Record: Actively maintained; recent stable-relevant bridge fixes in this
tree (UAF, sleep-in-atomic, FDB snapshot).

---

## PHASE 8: IMPACT AND RISK

**Step 8.1 — Who is affected**

Record: All systems using Linux bridge forwarding with dynamic FDB
learning and MAC roaming.

**Step 8.2 — Trigger conditions**

Record: Host moves between bridge ports; concurrent forwarding while
`br_fdb_update()` roams `fdb->dst`. Common in Wi-Fi/Ethernet mobility,
VM migration, and active L2 networks.

**Step 8.3 — Failure mode / severity**

Record:
- **Forwarding paths:** packet delivered to wrong port (connectivity bug
  / potential traffic leakage) — **MEDIUM-HIGH**
- **FDB management paths:** missed or incorrect entry handling during
  concurrent roam — **MEDIUM**
- **Kernel crash:** unlikely on these specific hunks (`br_forward()`
  handles `NULL`); sibling fix `5424e678` addressed a confirmed NULL-
  deref in sysfs path
- **KCSAN/data-race:** definite without fix — **MEDIUM** for
  CI/sanitizer builds

**Step 8.4 — Risk/benefit**

Record:
- **Benefit:** HIGH for bridge users with roaming; completes an already-
  stable-nominated fix family
- **Risk:** VERY LOW — 6-line annotation-only change matching
  established pattern
- **Ratio:** strongly favors backport

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1 — Evidence summary**

**FOR:**
- Real concurrency bug in hot forwarding path
- Small, surgical, maintainer-acked
- Prerequisites and related stable fix already in v6.18.44
- Applies cleanly
- Follows established subsystem convention since 2021
- Complements already-backported `5424e678f9b30`

**AGAINST:**
- No syzbot/crash report for these exact sites
- Primary user impact is mis-forwarding rather than panic
- Mailing list/stable discussion not verified

**UNRESOLVED:**
- Full lore review thread content
- Whether reviewers explicitly nominated for stable

**Step 9.2 — Stable rules checklist**

| Criterion | Result |
|---|---|
| 1. Obviously correct and tested? | **PASS** — pattern proven in-tree;
maintainer ack |
| 2. Fixes a real user-affecting bug? | **PASS** — roaming race in
forwarding/FDB paths |
| 3. Important issue? | **PASS** — forwarding correctness on common
bridge deployments |
| 4. Small and contained? | **PASS** — 6 lines, 3 files |
| 5. No new features/APIs? | **PASS** — annotation only |
| 6. Can apply to local tree? | **PASS** — clean dry-run apply; code and
writers present |

**Step 9.3 — Exception category**

Record: Not a device-ID/quirk/DT/build/doc exception; qualifies as a
standard concurrency correctness bug fix.

**Step 9.4 — Problem statement for stable users**

When a MAC address roams between bridge ports, `fdb->dst` is updated
locklessly. The remaining unannotated readers in transmit/receive
forwarding and FDB cleanup paths can observe a changing destination
port, causing frames to be forwarded to the wrong port or FDB
maintenance to behave incorrectly. This patch completes the
`READ_ONCE`/`WRITE_ONCE` pairing already used throughout the rest of the
bridge FDB code and in the recently backported `5424e678` fix.

---

## Verification

- [Phase 1] Parsed commit message and tags from user-provided diff
- [Phase 2] Diff analysis: 6 lines across `br_device.c`, `br_input.c`,
  `br_fdb.c`
- [Phase 3] `git describe HEAD` → `v6.18.44`
- [Phase 3] `git blame` on lines 110/226/473 → pre-2021 code missing
  annotations
- [Phase 3] `git show 3e19ae7c6fd62` → original `READ_ONCE`/`WRITE_ONCE`
  introduction
- [Phase 3] `git show 5424e678f9b30` → related stable-nominated FDB dst
  snapshot fix, already in tree
- [Phase 3] `git merge-base --is-ancestor` → both `3e19ae7` and
  `5424e678` are ancestors of HEAD
- [Phase 4] **UNVERIFIED:** lore.kernel.org and patch.msgid.link
  blocked; `b4 dig` not usable without local commit hash
- [Phase 5] `grep READ_ONCE.*dst` → most readers annotated; patched
  sites are outliers
- [Phase 5] Read `br_fdb_update()` → confirmed lockless
  `WRITE_ONCE(fdb->dst, source)` roaming path
- [Phase 5] Read `br_forward()` → confirmed `NULL` port handled safely
- [Phase 6] Read current sources → buggy plain loads confirmed present
- [Phase 6] `patch --dry-run` → applies cleanly
- [Phase 8] Assessed failure mode as mis-forwarding during roam, not
  typical kernel oops

**YES**

 net/bridge/br_device.c | 2 +-
 net/bridge/br_fdb.c    | 7 ++++---
 net/bridge/br_input.c  | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 525d4eccd194a..966fac7017225 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -107,7 +107,7 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
 		else
 			br_flood(br, skb, BR_PKT_MULTICAST, false, true, vid);
 	} else if ((dst = br_fdb_find_rcu(br, dest, vid)) != NULL) {
-		br_forward(dst->dst, skb, false, true);
+		br_forward(READ_ONCE(dst->dst), skb, false, true);
 	} else {
 		br_flood(br, skb, BR_PKT_UNICAST, false, true, vid);
 	}
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 6eb3ab69a5140..fe85c8f197e67 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -470,7 +470,8 @@ void br_fdb_changeaddr(struct net_bridge_port *p, const unsigned char *newaddr)
 	spin_lock_bh(&br->hash_lock);
 	vg = nbp_vlan_group(p);
 	hlist_for_each_entry(f, &br->fdb_list, fdb_node) {
-		if (f->dst == p && test_bit(BR_FDB_LOCAL, &f->flags) &&
+		if (READ_ONCE(f->dst) == p &&
+		    test_bit(BR_FDB_LOCAL, &f->flags) &&
 		    !test_bit(BR_FDB_ADDED_BY_USER, &f->flags)) {
 			/* delete old one */
 			fdb_delete_local(br, p, f);
@@ -878,7 +879,7 @@ void br_fdb_delete_by_port(struct net_bridge *br,
 
 	spin_lock_bh(&br->hash_lock);
 	hlist_for_each_entry_safe(f, tmp, &br->fdb_list, fdb_node) {
-		if (f->dst != p)
+		if (READ_ONCE(f->dst) != p)
 			continue;
 
 		if (!do_all)
@@ -1660,7 +1661,7 @@ void br_fdb_clear_offload(const struct net_device *dev, u16 vid)
 
 	spin_lock_bh(&p->br->hash_lock);
 	hlist_for_each_entry(f, &p->br->fdb_list, fdb_node) {
-		if (f->dst == p && f->key.vlan_id == vid)
+		if (READ_ONCE(f->dst) == p && f->key.vlan_id == vid)
 			clear_bit(BR_FDB_OFFLOADED, &f->flags);
 	}
 	spin_unlock_bh(&p->br->hash_lock);
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 2cbae0f9ae1f0..470615675bdc0 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -223,7 +223,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
 
 		if (now != READ_ONCE(dst->used))
 			WRITE_ONCE(dst->used, now);
-		br_forward(dst->dst, skb, local_rcv, false);
+		br_forward(READ_ONCE(dst->dst), skb, local_rcv, false);
 	} else {
 		if (!mcast_hit)
 			br_flood(br, skb, pkt_type, local_rcv, false, vid);
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] bridge: Do not suppress ARP probes and DAD NS unconditionally

[Sasha Levin]

From: Danielle Ratson <danieller@nvidia.com>

[ Upstream commit fee1fc1d5a5475f5516d406a03e443348cd0f06c ]

When neighbor suppression is enabled on a VXLAN port, the bridge is
expected to reply to ARP/NS messages on behalf of remote hosts when both
FDB and neighbor entries exist. This allows the bridge to suppress
flooding of these messages to the VXLAN overlay.

According to RFC 9161 ("Operational Aspects of Proxy ARP/ND in Ethernet
Virtual Private Networks"):
"A PE SHOULD reply to broadcast/multicast address resolution messages,
i.e., ARP Requests, ARP probes, NS messages, as well as DAD NS messages.
An ARP probe is an ARP Request constructed with an all-zero sender IP
address that may be used by hosts for IPv4 Address Conflict Detection as
specified in [RFC5227]".

However, the current implementation unconditionally suppresses ARP probes
and DAD Neighbor Solicitations, which breaks Duplicate Address Detection
(DAD) over EVPN.

For DAD to work correctly over the VXLAN fabric:
- When the bridge does not know the answer:
  flood the probe/DAD packet to allow remote VTEPs to respond.
- When the bridge knows the answer:
  reply to indicate the address is in use.

Fix by adjusting the early suppression checks to exclude ARP probes and
DAD NS from unconditional suppression.

When replying to a DAD NS, br_nd_send() is adjusted to set the NA
destination to the all-nodes multicast address (ff02::1) and clear the
Solicited flag, in accordance with RFC 4861 section 7.2.4.

Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Danielle Ratson <danieller@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://patch.msgid.link/20260429062405.1386417-2-danieller@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: bridge: Do not suppress ARP probes and DAD
NS unconditionally

**Local tree:** Linux **6.18.43** (`git describe HEAD` →
`v6.18.43-1-gc7f0dac02d232`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[bridge]` `[fix implicit: "Do not"]` — Stop unconditionally
suppressing ARP probes and DAD Neighbor Solicitations when neighbor
suppression is enabled on bridge/VXLAN ports.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Reviewed-by:** Ido Schimmel \<idosch@nvidia.com\> (bridge
  maintainer)
- **Acked-by:** Nikolay Aleksandrov \<razor@blackwall.org\> (bridge
  maintainer)
- **Signed-off-by:** Danielle Ratson \<danieller@nvidia.com\> (author)
- **Signed-off-by:** Jakub Kicinski \<kuba@kernel.org\> (netdev
  maintainer)
- **Link:**
  https://patch.msgid.link/20260429062405.1386417-2-danieller@nvidia.com
  (patch 2/N in series)
- No Fixes:, Reported-by:, Tested-by:, or Cc: stable tags
- Notable: dual maintainer review (Ido Schimmel + Nikolay Aleksandrov
  Ack)

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** With `BR_NEIGH_SUPPRESS` enabled on VXLAN ports, the bridge
  unconditionally suppresses ARP probes (sender IP 0.0.0.0) and DAD NS
  (source address ::), preventing them from being flooded or proxied.
- **Symptom:** Duplicate Address Detection (DAD) fails over EVPN/VXLAN
  fabrics; hosts cannot detect address conflicts across the overlay.
- **RFC basis:** RFC 9161 says PEs SHOULD reply to (or forward) ARP
  probes and DAD NS; RFC 4861 §7.2.4 governs DAD NA format.
- **Expected behavior:** Flood probe/DAD when unknown; proxy-reply when
  FDB+neighbor entry exist.
- **Root cause:** Early-return suppression checks treat probe/DAD
  packets the same as other suppressible traffic by matching
  `ipv4_is_zeronet(sip)` and `ipv6_addr_any(saddr)`.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not disguised — this is an explicit protocol-correctness bug
fix, not cleanup. The `br_nd_send()` changes fix incorrect NA
destination (unicast to ::) and wrong Solicited flag for DAD replies.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **Files:** `net/bridge/br_arp_nd_proxy.c` only (+14 / -8 lines net)
- **Functions modified:** `br_do_proxy_suppress_arp()`, `br_nd_send()`,
  `br_do_suppress_nd()`
- **Scope:** Single-file surgical fix

### Step 2.2: CODE FLOW CHANGE (per hunk)

**Hunk 1 — `br_do_proxy_suppress_arp()`:**
- **Before:** `(ipv4_is_zeronet(sip) || sip == tip)` → set
  `proxyarp_replied=1`, return (drop from flooding).
- **After:** Only `sip == tip` triggers early suppression; ARP probes
  (sip=0.0.0.0) fall through to lookup/flood/proxy logic.

**Hunk 2–4 — `br_nd_send()`:**
- **Before:** Always unicast NA to requester; always set Solicited=1.
- **After:** Detect DAD (`ipv6_addr_any(saddr)`); for DAD, multicast NA
  to all-nodes (ff02::1), clear Solicited flag per RFC 4861.

**Hunk 5 — `br_do_suppress_nd()`:**
- **Before:** `ipv6_addr_any(saddr) || saddr==daddr` → suppress
  unconditionally.
- **After:** Only `saddr==daddr` suppressed; DAD NS (saddr=::) processed
  normally.

### Step 2.3: BUG MECHANISM
**Record:** **Logic/correctness fix** in neighbor-suppression proxy
path. Setting `proxyarp_replied=1` causes `br_forward.c` to skip
flooding to `BR_NEIGH_SUPPRESS` ports:

```233:236:net/bridge/br_forward.c
                if (BR_INPUT_SKB_CB(skb)->proxyarp_replied &&
                    ((p->flags & BR_PROXYARP_WIFI) ||
                     br_is_neigh_suppress_enabled(p, vid)))
                        continue;
```

Unconditional suppression of probes/DAD meant these packets never
reached remote VTEPs, breaking cross-overlay DAD.

### Step 2.4: FIX QUALITY
**Record:** Fix is minimal, RFC-aligned, and obviously correct.
Regression risk is low — only narrows the early-suppression condition;
`sip==tip` and `saddr==daddr` cases retain prior behavior. No new locks
or APIs.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:** Buggy suppression logic dates to **ed842faeb2bd** (Oct 2017,
"bridge: suppress nd pkts on BR_NEIGH_SUPPRESS ports" by Roopa Prabhu).
Original commit already had `ipv4_is_zeronet(sip)` and
`ipv6_addr_any(saddr)` checks. Present in this 6.18.43 tree.

### Step 3.2: FOLLOW THE FIXES: TAG
**Record:** No Fixes: tag in commit message. Related stable fixes in
same file reference `Fixes: ed842faeb2bd` (e.g. `837392a384457`,
`9c55e41c73af5` for `br_nd_send()` hardening). The introducing commit
**is** in this tree.

### Step 3.3: FILE HISTORY FOR RELATED CHANGES
**Record:** Recent changes to `br_arp_nd_proxy.c` in this tree:
- `5424e678f9b30` — FDB dst snapshot (RCU)
- `837392a384457` — ND option length validation (Cc: stable)
- `9c55e41c73af5` — skb linearize before ND parsing (Cc: stable)
- File introduced at Linux 6.18-rc7 (split from prior monolithic bridge
  code; logic unchanged since 2017)

### Step 3.4: AUTHOR'S OTHER COMMITS
**Record:** Danielle Ratson has no other commits in `net/bridge/` in
this checkout. Fix author is NVIDIA bridge contributor; reviewers are
subsystem maintainers.

### Step 3.5: DEPENDENT/PREREQUISITE COMMITS
**Record:** Message-ID indicates patch **2/N** in a series. The diff is
self-contained in one file with no new symbols or structures. `git apply
--check` succeeds cleanly against current tree. No code dependencies
identified; patch 1 may be documentation/tests (unverified).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: ORIGINAL PATCH DISCUSSION
**Record:** UNVERIFIED — lore.kernel.org and patch.msgid.link blocked by
bot protection. `b4 dig -c <commit>` not possible (commit not in local
tree). Message-ID suffix `-2-` confirms multi-patch series.

### Step 4.2: REVIEWERS
**Record:** UNVERIFIED via b4 dig -w. Commit message shows Reviewed-by
Ido Schimmel and Acked-by Nikolay Aleksandrov (verified bridge
maintainers from prior commits in tree).

### Step 4.3: BUG REPORT
**Record:** No Reported-by or bugzilla/syzbot links. Bug identified via
RFC 9161 compliance analysis by author.

### Step 4.4: RELATED PATCHES/SERIES
**Record:** Part of Danielle Ratson series (patch 2). Same file recently
received stable-nominated `br_nd_send()` fixes from different authors.
This patch is logically independent.

### Step 4.5: STABLE MAILING LIST
**Record:** UNVERIFIED — could not access lore stable archive.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: KEY FUNCTIONS
**Record:** `br_do_proxy_suppress_arp()`, `br_nd_send()`,
`br_do_suppress_nd()`

### Step 5.2: CALLERS
**Record:**
- `br_input.c:172` — ingress path for every ARP/RARP frame on bridge
  ports
- `br_input.c:183` — ingress path for IPv6 ND when neighbor suppress
  enabled
- `br_device.c:76,87` — bridge device xmit path

All are hot networking paths reachable during normal host traffic and
address configuration.

### Step 5.3: CALLEES
**Record:** `neigh_lookup()`, `br_fdb_find_rcu()`, `br_arp_send()`,
`br_nd_send()`, `br_is_neigh_suppress_enabled()`, `ipv6_eth_mc_map()`,
`in6addr_linklocal_allnodes` (all present in tree).

### Step 5.4: CALL CHAIN / REACHABILITY
**Record:** Userspace/host DAD and ARP probe → bridge ingress
(`br_handle_frame_finish`) →
`br_do_proxy_suppress_arp`/`br_do_suppress_nd` → sets `proxyarp_replied`
→ affects flooding in `__br_forward`. **Reachable from normal network
traffic** on EVPN/VXLAN deployments with neighbor suppression.

### Step 5.5: SIMILAR PATTERNS
**Record:** Kernel's own `ndisc.c` already handles DAD NA with
`in6addr_linklocal_allnodes` and Solicited=0 — the fix aligns bridge
proxy behavior with core ND stack.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE

### Step 6.1: DOES THE BUGGY CODE EXIST?
**Record:** **YES.** Verified at:
- `br_arp_nd_proxy.c:168` — `(ipv4_is_zeronet(sip) || sip == tip)`
- `br_arp_nd_proxy.c:439` — `ipv6_addr_any(saddr) ||
  !ipv6_addr_cmp(saddr, daddr)`
- `br_nd_send()` lacks DAD handling (lines 305, 321, 334)

Bug present since ed842faeb2bd (2017), well before 6.18 branch.

### Step 6.2: BACKPORT COMPLICATIONS
**Record:** **Clean apply** — `git apply --check
/tmp/bridge_dad_fix.patch` succeeds with no conflicts. No refactoring
churn in the changed hunks since the 6.18 file split.

### Step 6.3: RELATED FIXES ALREADY PRESENT?
**Record:** `git log --grep="Do not suppress ARP"` returns nothing. Fix
**not** yet in this tree. Related `br_nd_send()` hardening commits are
present but do not address DAD suppression.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
**Record:** **net/bridge** — IMPORTANT. Affects datacenter EVPN/VXLAN
overlay networking; not universal but widely deployed in
cloud/enterprise fabrics.

### Step 7.2: SUBSYSTEM ACTIVITY
**Record:** Active — multiple bridge commits in 6.18.y including UAF
fixes, netfilter bridge fixes, and neighbor-suppress-related patches.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
**Record:** Users running Linux bridges with **neighbor suppression**
(`BR_NEIGH_SUPPRESS` / VLAN neigh suppress) over **VXLAN/EVPN**
overlays. Config-specific, but targets production datacenter networking.

### Step 8.2: TRIGGER CONDITIONS
**Record:** Host performs IPv4 ACD (ARP probe) or IPv6 DAD (NS with ::
source) on a VLAN behind a bridge with neighbor suppression toward VXLAN
ports. **Common during interface bring-up and address assignment.**
Unprivileged users can trigger DAD on their own interfaces.

### Step 8.3: FAILURE MODE SEVERITY
**Record:** DAD silently fails → duplicate IP addresses may go
undetected across VTEPs → connectivity blackholes, flapping, or traffic
hijacking. **Not a kernel oops**, but **HIGH operational severity** for
affected deployments (silent network misconfiguration).

### Step 8.4: RISK-BENEFIT
**Record:**
- **Benefit:** HIGH for EVPN/VXLAN users — restores RFC-compliant
  DAD/ACD behavior
- **Risk:** LOW — ~20 lines, narrow condition change, maintainer-
  reviewed
- **Ratio:** Strong benefit for affected users, minimal regression risk

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE COMPILED

**FOR backport:**
- Real, long-standing bug (since 2017) present in 6.18.43
- Breaks DAD/ACD over EVPN — concrete user impact
- RFC 9161 / RFC 4861 compliance
- Small, surgical, applies cleanly
- Reviewed by bridge maintainers (Schimmel, Aleksandrov)
- Same file recently had other fixes nominated to stable
- Fixes incorrect DAD NA format in `br_nd_send()` (would send unicast NA
  to ::)

**AGAINST backport:**
- Not a kernel crash, security CVE, or memory corruption
- Only affects neighbor-suppress + overlay configurations
- No user bug reports or syzbot in commit message
- Lore/stable discussion unverified

**UNRESOLVED:**
- Full mailing list thread and whether patch 1/N is required
- Whether reviewers explicitly nominated for stable

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — RFC-aligned logic;
   maintainer-reviewed (no Tested-by)
2. Fixes a real bug affecting users? **PASS** — DAD broken on EVPN/VXLAN
   with neigh suppress
3. Important issue? **PASS** — silent DAD failure → duplicate IPs /
   overlay misconfiguration (HIGH operational impact for affected
   configs)
4. Small and contained? **PASS** — single file, ~20 lines
5. No new features/APIs? **PASS** — behavior correction only
6. Can apply to local tree? **PASS** — verified clean apply

### Step 9.3: EXCEPTION CATEGORIES
**Record:** None (not device ID, quirk, DT, build, or docs). Standard
protocol-correctness bug fix.

### Step 9.4: DECISION RATIONALE

For **Linux 6.18.y**, this fix should be backported. The buggy code is
present, has been there since the 2017 neighbor-suppression feature, and
the patch restores essential DAD/ACD behavior required for correct EVPN
operation per RFC 9161. While not a kernel panic, broken duplicate-
address detection in overlay networks is a serious, user-visible
correctness bug in a configuration pattern common in production
datacenter deployments. The fix is minimal, applies cleanly, and carries
maintainer endorsement.

---

## Verification

- **[Phase 1]** Parsed subject, tags (Reviewed-by, Acked-by, Link), and
  body text from provided commit message
- **[Phase 2]** Analyzed full diff: 3 functions, 1 file, logic-
  classification as protocol correctness
- **[Phase 3]** `git describe HEAD` → v6.18.43; Makefile → 6.18.43
- **[Phase 3]** `git show ed842faeb2bd` → original 2017 commit with same
  buggy conditions; commit exists in tree
- **[Phase 3]** `git blame` / `git log --oneline ed842faeb2bd..HEAD --
  net/bridge/br_arp_nd_proxy.c` → bug predates 6.18
- **[Phase 3]** `git log --grep="Do not suppress ARP"` → empty; fix not
  present
- **[Phase 4]** WebFetch lore.kernel.org → blocked (bot protection);
  **UNVERIFIED** mailing list discussion
- **[Phase 4]** `b4 dig -c` → cannot use (commit not in tree);
  **UNVERIFIED** series patch 1 content
- **[Phase 5]** `grep br_do_proxy_suppress_arp/br_do_suppress_nd` →
  callers in `br_input.c`, `br_device.c`
- **[Phase 5]** `grep proxyarp_replied` → flooding gate in
  `br_forward.c:233-236`
- **[Phase 5]** `grep in6addr_linklocal_allnodes/ipv6_eth_mc_map` →
  symbols exist in tree
- **[Phase 6]** `grep` confirmed buggy lines at 168 and 439 in current
  tree
- **[Phase 6]** `git apply --check /tmp/bridge_dad_fix.patch` → **clean
  apply**
- **[Phase 6]** `git log --grep` → no duplicate fix already applied
- **[Phase 7]** `git log --oneline -20 -- net/bridge/` → active
  subsystem
- **[Phase 8]** Failure mode assessed from code path: `proxyarp_replied`
  blocks flooding to neigh-suppress ports

**YES**The background `git log -S "BR_NEIGH_SUPPRESS"` search timed out
because it scanned the full repo history. I killed it and reran a scoped
search under `net/bridge/` instead.

That narrower search wasn’t very useful on its own (it only hit the
tree-import commit), but the analysis already had the real answer from
`git show ed842faeb2bd`: neighbor suppression and the buggy probe/DAD
suppression logic were introduced in October 2017 and are present in
this 6.18.43 tree.

The backport recommendation stands: **YES** — a small, RFC-aligned fix
for broken DAD/ACD over EVPN/VXLAN when neighbor suppression is enabled.

 net/bridge/br_arp_nd_proxy.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/bridge/br_arp_nd_proxy.c b/net/bridge/br_arp_nd_proxy.c
index 7ace0f4941bb6..4cd3470e5f56c 100644
--- a/net/bridge/br_arp_nd_proxy.c
+++ b/net/bridge/br_arp_nd_proxy.c
@@ -165,7 +165,7 @@ void br_do_proxy_suppress_arp(struct sk_buff *skb, struct net_bridge *br,
 			return;
 		if (parp->ar_op != htons(ARPOP_RREQUEST) &&
 		    parp->ar_op != htons(ARPOP_RREPLY) &&
-		    (ipv4_is_zeronet(sip) || sip == tip)) {
+		    sip == tip) {
 			/* prevent flooding to neigh suppress ports */
 			BR_INPUT_SKB_CB(skb)->proxyarp_replied = 1;
 			return;
@@ -263,6 +263,7 @@ static void br_nd_send(struct net_bridge *br, struct net_bridge_port *p,
 	int ns_olen;
 	int i, len;
 	u8 *daddr;
+	bool dad;
 	u16 pvid;
 
 	if (!dev || skb_linearize(request))
@@ -301,8 +302,13 @@ static void br_nd_send(struct net_bridge *br, struct net_bridge_port *p,
 		}
 	}
 
+	dad = ipv6_addr_any(&ipv6_hdr(request)->saddr);
+
 	/* Ethernet header */
-	ether_addr_copy(eth_hdr(reply)->h_dest, daddr);
+	if (dad)
+		ipv6_eth_mc_map(&in6addr_linklocal_allnodes, eth_hdr(reply)->h_dest);
+	else
+		ether_addr_copy(eth_hdr(reply)->h_dest, daddr);
 	ether_addr_copy(eth_hdr(reply)->h_source, n->ha);
 	eth_hdr(reply)->h_proto = htons(ETH_P_IPV6);
 	reply->protocol = htons(ETH_P_IPV6);
@@ -318,7 +324,7 @@ static void br_nd_send(struct net_bridge *br, struct net_bridge_port *p,
 	pip6->priority = ipv6_hdr(request)->priority;
 	pip6->nexthdr = IPPROTO_ICMPV6;
 	pip6->hop_limit = 255;
-	pip6->daddr = ipv6_hdr(request)->saddr;
+	pip6->daddr = dad ? in6addr_linklocal_allnodes : ipv6_hdr(request)->saddr;
 	pip6->saddr = *(struct in6_addr *)n->primary_key;
 
 	skb_pull(reply, sizeof(struct ipv6hdr));
@@ -331,7 +337,7 @@ static void br_nd_send(struct net_bridge *br, struct net_bridge_port *p,
 	na->icmph.icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT;
 	na->icmph.icmp6_router = (n->flags & NTF_ROUTER) ? 1 : 0;
 	na->icmph.icmp6_override = 1;
-	na->icmph.icmp6_solicited = 1;
+	na->icmph.icmp6_solicited = dad ? 0 : 1;
 	na->target = ns->target;
 	ether_addr_copy(&na->opt[2], n->ha);
 	na->opt[0] = ND_OPT_TARGET_LL_ADDR;
@@ -436,7 +442,7 @@ void br_do_suppress_nd(struct sk_buff *skb, struct net_bridge *br,
 	saddr = &iphdr->saddr;
 	daddr = &iphdr->daddr;
 
-	if (ipv6_addr_any(saddr) || !ipv6_addr_cmp(saddr, daddr)) {
+	if (!ipv6_addr_cmp(saddr, daddr)) {
 		/* prevent flooding to neigh suppress ports */
 		BR_INPUT_SKB_CB(skb)->proxyarp_replied = 1;
 		return;
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()

[Sasha Levin]

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit 25ae123db10ba9ab890b56bcdb0a4363aee8529a ]

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

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://patch.msgid.link/20260519095540.2643318-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject Line
**Record:** `[net: bridge]` `[remove]` — remove a stale `rcu_barrier()`
call from `br_multicast_dev_del()`.

### Step 1.2: Commit Message Tags
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — not present; syzbot impact described in body
- **Tested-by:** — not present
- **Reviewed-by:** Jakub Sitnicki `<jakub@cloudflare.com>`, Ido Schimmel
  `<idosch@nvidia.com>`
- **Acked-by:** Nikolay Aleksandrov `<razor@blackwall.org>` (bridge
  multicast maintainer)
- **Link:**
  https://patch.msgid.link/20260519095540.2643318-1-edumazet@google.com
- **Cc: stable:** — not present (not a negative signal)
- **Signed-off-by:** Eric Dumazet, Jakub Kicinski (ignore pipeline-added
  SOBs)

Notable: maintainer ack + two subsystem reviewers; syzbot deadlock stack
trace in body.

### Step 1.3: Commit Body Analysis
**Record:**
- **Bug:** `rcu_barrier()` in `br_multicast_dev_del()` is leftover from
  the `call_rcu()` era; multicast teardown now uses `kfree_rcu()`.
- **Symptom:** Extreme RTNL pressure; syzbot reports tasks blocked on
  mutex during `cleanup_net` workqueue processing.
- **Failure mode:** `cleanup_net` → `ops_exit_rtnl_list` (RTNL held) →
  `unregister_netdevice_many` → `br_dev_uninit` → `br_multicast_dev_del`
  → `rcu_barrier()` → hung task waiting on completion while kworker
  holds RTNL.
- **Root cause (author):** Global `rcu_barrier()` drains unrelated RCU
  callbacks while RTNL is held, creating lock-order / pressure problems.

### Step 1.4: Hidden Bug Fix Detection
**Record:** Yes — described as cleanup, but it fixes a real
hang/deadlock during network namespace teardown. Not cosmetic.

---

## Phase 2: Diff Analysis

### Step 2.1: Change Inventory
**Record:**
- **Files:** `net/bridge/br_multicast.c` only (−2 lines)
- **Function:** `br_multicast_dev_del()`
- **Scope:** Single-file, surgical deletion

### Step 2.2: Code Flow Change
**Record:**
- **Before:** After synchronous GC (`br_multicast_gc`) and
  `cancel_work_sync(&br->mcast_gc_work)`, call global `rcu_barrier()`.
- **After:** Return immediately after GC work is synchronized.
- **Path affected:** Bridge netdev teardown during namespace/device
  unregistration (error/cleanup path, not hot path).

### Step 2.3: Bug Mechanism
**Record:** **Category:** Deadlock / hung task from unnecessary global
synchronization.
- `rcu_barrier()` waits for all RCU callbacks system-wide.
- Called under RTNL during `cleanup_net`.
- Other workers may need RTNL to complete their RCU callbacks → circular
  wait.
- With `kfree_rcu()` only (no `call_rcu()` in this file), the barrier
  has no bridge-multicast callbacks of its own to wait for; it only
  stalls unrelated subsystems.

### Step 2.4: Fix Quality
**Record:** Obviously correct and minimal. Bridge maintainer confirmed
the barrier is stale. Regression risk is very low: synchronous GC +
`cancel_work_sync` already ensure teardown ordering; `kfree_rcu` handles
deferred freeing without a global barrier. Precedent: `writeback: drop
now-unnecessary rcu_barrier()` was backported to stable (commit
`29de8448174cf` in this tree).

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:**
- `rcu_barrier()` at line 4460 introduced by Nikolay Aleksandrov, commit
  `4329596cb10d23` (2018-12-05), when switching from `call_rcu_bh` to
  `kfree_rcu`.
- `cancel_work_sync` added in `e12cec65b5546` (2020-09-07) with the GC
  refactor.
- Bug present since 2018; deadlock surfaced under syzbot stress.

### Step 3.2: Fixes: Tag
**Record:** N/A — no `Fixes:` tag. Original introduction:
`4329596cb10d23` ("net: bridge: multicast: use non-bh rcu flavor"),
which is an ancestor of this tree.

### Step 3.3: Related File History
**Record:**
- `4329596cb10d23`: `call_rcu_bh` → `kfree_rcu`, kept `rcu_barrier()`
  (changed from `rcu_barrier_bh()`).
- `e12cec65b5546`: GC refactor; `br_multicast_dev_del` now uses
  synchronous `br_multicast_gc()`.
- No `call_rcu` remains in `br_multicast.c` (verified).
- Standalone one-patch series (v1 only per `b4 dig -a`).

### Step 3.4: Author Context
**Record:** Eric Dumazet is a senior networking developer. Nikolay
Aleksandrov (bridge maintainer) acked. No conflicting follow-up fixes
found.

### Step 3.5: Dependencies
**Record:** No dependencies. Prerequisites (`kfree_rcu` migration, GC
refactor) are both ancestors of HEAD. Patch applies cleanly (`git apply
--check` → **APPLIES CLEANLY**). Fix commit `25ae123db10ba` is **NOT**
in this tree.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:**
- `b4 dig -c 25ae123db10ba` →
  https://patch.msgid.link/20260519095540.2643318-1-edumazet@google.com
- Single revision (v1, 2026-05-19).
- Nikolay Aleksandrov: **Acked-by** — confirms barrier is no longer
  needed.
- No NAKs found in thread.
- No explicit `Cc: stable` in thread, but that is not required.

### Step 4.2: Reviewers
**Record:** CC'd: David Miller, Jakub Kicinski, Paolo Abeni, Simon
Horman, netdev@, Nikolay Aleksandrov, Ido Schimmel. Appropriate
maintainers/reviewers involved.

### Step 4.3: Bug Report
**Record:** syzbot-style hung-task trace in commit message and patch.
Task blocked on mutex during `cleanup_net` / `rcu_barrier`. Reproducible
under fuzzing; affects netns teardown with bridges.

### Step 4.4: Related Patches
**Record:** Standalone patch, not part of a series. Similar pattern in
writeback (`29de8448174cf`, already backported here).

### Step 4.5: Stable List History
**Record:** Not searched on lore stable@ (WebFetch blocked by bot
protection for direct lore). No evidence this was rejected for stable.
Fix is not yet in `stable/linux-6.18.y`.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `br_multicast_dev_del()` modified.

### Step 5.2: Callers
**Record:**
- `br_dev_uninit()` in `net/bridge/br_device.c:157` — called during
  netdev unregistration.
- Reachable from `unregister_netdevice_many()` → `ops_exit_rtnl_list()`
  → `cleanup_net` workqueue.
- Affects all bridge teardown when `CONFIG_BRIDGE_IGMP_SNOOPING` is
  enabled.

### Step 5.3: Callees
**Record:** `br_multicast_del_mdb_entry`, `br_multicast_ctx_deinit`,
`br_multicast_gc`, `cancel_work_sync`, (removed) `rcu_barrier`.
- `br_multicast_gc` synchronously calls destroy callbacks that use
  `kfree_rcu()` for mdb entries, port groups, and group sources.

### Step 5.4: Call Chain / Reachability
**Record:**
`unshare(CLONE_NEWNET)` / container stop / `ip netns delete` → netns
refcount drop → `cleanup_net` → bridge device unregister →
`br_multicast_dev_del`. Userspace-triggerable via namespace lifecycle;
common in containers.

### Step 5.5: Similar Patterns
**Record:**
- `br.c:506` still has `rcu_barrier()` at **module unload** — different
  context (fdb kmem_cache teardown), intentionally kept.
- `writeback` had identical stale-`rcu_barrier` removal backported to
  stable.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** Local tree is **Linux 6.18.44**
(`stable/linux-6.18.y`). `rcu_barrier()` present at
`net/bridge/br_multicast.c:4460`. Fix commit `25ae123db10ba` is **not**
merged.

### Step 6.2: Backport Complications
**Record:** Clean apply confirmed. No conflicting refactors in this
function between mainline fix and 6.18.y.

### Step 6.3: Related Fixes Already Present?
**Record:** No equivalent fix in tree. `git grep "remove stale
rcu_barrier"` returns nothing. Prerequisites (`kfree_rcu`, GC refactor)
are present.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem Criticality
**Record:** **net/bridge** — IMPORTANT. Bridge is widely used in
virtualization, containers, and enterprise networking.

### Step 7.2: Subsystem Activity
**Record:** Actively maintained; recent multicast fixes from Nikolay
Aleksandrov in 6.18.y.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Users with `CONFIG_BRIDGE` + `CONFIG_BRIDGE_IGMP_SNOOPING`
who tear down bridges during network namespace cleanup (containers, LXC,
Kubernetes CNI, test harnesses).

### Step 8.2: Trigger Conditions
**Record:** Network namespace deletion with bridge devices present.
syzbot reproduces under stress. Not every boot, but realistic in
container orchestration. Unprivileged users can trigger via user
namespaces + bridge setup.

### Step 8.3: Failure Severity
**Record:** Hung task / RTNL deadlock during cleanup — **CRITICAL**
(namespace teardown stalls, can leave system in degraded state).

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** HIGH — prevents real hangs in namespace teardown.
- **Risk:** VERY LOW — 2-line deletion, maintainer-acked, synchronous GC
  already in place.
- **Ratio:** Strongly favors backport.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR:**
- Real, reproducible hung-task / RTNL pressure (syzbot).
- Critical failure mode during netns cleanup.
- Minimal, maintainer-acked fix.
- Buggy code present in 6.18.44.
- Applies cleanly.
- `kfree_rcu` has been used since 2018; `rcu_barrier` is genuinely
  stale.
- Precedent: similar `rcu_barrier` removal backported in writeback.

**AGAINST:**
- Only affects configs with bridge IGMP snooping (not universal, but
  very common in distros).
- No explicit `Cc: stable` (irrelevant per review rules).

**UNRESOLVED:**
- Exact syzkaller bug URL not fetched (lore bot-blocked); stack trace in
  commit is sufficient.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — maintainer ack, two reviews,
   syzbot validation.
2. Fixes a real bug? **PASS** — hung task during netns cleanup.
3. Important issue? **PASS** — deadlock/hang, CRITICAL severity.
4. Small and contained? **PASS** — 2 lines, 1 file.
5. No new features/APIs? **PASS** — deletion only.
6. Can apply to local tree? **PASS** — clean apply verified.

### Step 9.3: Exception Categories
**Record:** Not a device-ID/quirk/DT/build/doc exception. Qualifies as a
straight bug fix.

### Step 9.4: Decision Rationale
The stale `rcu_barrier()` in `br_multicast_dev_del()` causes real hangs
when bridges are torn down during network namespace cleanup. The barrier
was needed for `call_rcu()` callbacks that no longer exist — all
multicast objects now use `kfree_rcu()` with synchronous GC beforehand.
Removing it is safe, tiny, and maintainer-approved. The bug exists in
Linux 6.18.44 and the fix applies cleanly.

---

## Verification

- [Phase 1] `git show 25ae123db10ba`: parsed subject, tags, body, stack
  trace
- [Phase 2] Read `br_multicast_dev_del()` at lines 4444–4461; confirmed
  −2 line diff
- [Phase 2] `grep call_rcu net/bridge/br_multicast.c`: no matches (only
  `kfree_rcu`)
- [Phase 3] `git blame -L 4458,4461`: `rcu_barrier` from
  `4329596cb10d23` (2018)
- [Phase 3] `git show 4329596cb10d23`: `call_rcu_bh` → `kfree_rcu`, kept
  `rcu_barrier`
- [Phase 3] `git show e12cec65b5546`: GC refactor with synchronous
  destroy
- [Phase 3] `git merge-base --is-ancestor`: both prerequisite commits in
  tree
- [Phase 3] `git merge-base --is-ancestor 25ae123db10ba HEAD`: **NOT IN
  TREE**
- [Phase 3] `git apply --check`: **APPLIES CLEANLY**
- [Phase 4] `b4 dig -c 25ae123db10ba`: lore URL found
- [Phase 4] `b4 dig -w`: netdev maintainers CC'd
- [Phase 4] `b4 dig -a`: v1 only, no later revisions
- [Phase 4] mbox: Acked-by Nikolay Aleksandrov; Reviewed-by Sitnicki,
  Schimmel
- [Phase 5] `grep br_multicast_dev_del`: caller `br_dev_uninit` at
  `br_device.c:157`
- [Phase 5] Read `ops_exit_rtnl_list` at `net_namespace.c:165–189`: RTNL
  held during unregister
- [Phase 5] Read `br_multicast_gc` at lines 893–902: synchronous destroy
  with `kfree_rcu`
- [Phase 6] `git describe HEAD`: v6.18.44; `make kernelversion`: 6.18.44
- [Phase 6] Confirmed `rcu_barrier()` at line 4460 still present
- [Phase 6] `git log stable/linux-6.18.y --grep="stale rcu_barrier"`: no
  match
- [Phase 8] `git show 29de8448174cf`: precedent for stale `rcu_barrier`
  removal in stable
- [Phase 8] `grep rcu_barrier net/bridge/`: only `br_multicast.c:4460`
  and `br.c:506` (module exit)

**YES**The background checks finished and match the earlier analysis.

**Task 65367** (`git log -S "rcu_barrier"` on `br_multicast.c`): the
only relevant hit was `10cc2b50eb4b0` (RCU race fix in
`br_multicast_stop`). The `rcu_barrier()` in `br_multicast_dev_del()`
came from the 2018 `kfree_rcu` migration (`4329596cb10d23`).

**Task 65368** (stable branch search): the fix commit `25ae123db10ba` is
**not** in `stable/linux-6.18.y`. The stale `rcu_barrier()` is still
present at line 4460 in this tree.

**Verdict unchanged: YES** — backport to Linux 6.18.y. It’s a 2-line
removal that fixes syzbot-reported hangs during netns/bridge teardown,
applies cleanly, and is acked by the bridge maintainer.

 net/bridge/br_multicast.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index ce34881a9d96e..1014f6221472e 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -4456,8 +4456,6 @@ void br_multicast_dev_del(struct net_bridge *br)
 	br_multicast_ctx_deinit(&br->multicast_ctx);
 	br_multicast_gc(&deleted_head);
 	cancel_work_sync(&br->mcast_gc_work);
-
-	rcu_barrier();
 }
 
 int br_multicast_set_router(struct net_bridge_mcast *brmctx, unsigned long val)
-- 
2.53.0