Harden guest TAP bridge ports against cross-guest frame leakage

[ulziibay-kernel]

Summary

Guest VMs on a shared bridge can passively capture unicast frames addressed to other guests. Port isolation is already enabled on isolated networks, but it only blocks guest-to-guest forwarding: when the bridge has no FDB entry for a destination MAC (aged out, or a guest that was just deleted while upstream packets were still in flight), it floods the frame to every port, including other guests' TAPs. A guest with a raw socket sees those frames.

This applies the standard multi-tenant bridge-port hardening to each guest TAP on isolated networks, right after isolation is set:

step	effect
permanent FDB entry (bridge fdb replace <mac> dev <tap> master permanent)	inbound delivery to the guest never depends on flooding, and learning cannot relocate the entry
LinkSetFlood(tap, false)	unknown-unicast frames are never flooded to the guest port
LinkSetLearning(tap, false)	a guest cannot poison the FDB by spoofing a source MAC (which could blackhole or misdirect neighbours' traffic)

The three steps live in hardenIsolatedPort. The FDB entry is built (and the MAC parsed) before the port is touched, so an unparseable MAC leaves the port at its defaults rather than flooding-off with nothing pinned to it.

createTAPDevice now takes the allocated guest MAC; both call sites (CreateAllocation, RecreateAllocation) already had it. Only isolated networks are affected — non-isolated networks keep their current behaviour.

Notes for review

• Learning-off is the one step with blast radius. With every guest MAC pinned statically it is safe, but it means a guest that changes its own MAC in-guest loses inbound until it changes back. That is an unsupported configuration, and it is what closes the FDB-poisoning vector, so I kept it — happy to drop it to a follow-up if you'd rather land flood-off + static FDB first.
• Failures in the new steps fail TAP creation, matching how the existing isolation step behaves.
• FDB entries are per-port and are removed by the kernel when the TAP is deleted, so no cleanup path was needed; TAP GC is unaffected.
• The entry is installed with NeighSet (NLM_F_REPLACE) rather than NeighAppend: NLM_F_APPEND carries multi-destination semantics, and replace is the idempotent primitive for pinning a single unicast MAC. NeighAdd (NLM_F_EXCL) is wrong here — it returns EEXIST if the MAC is still pinned to a stale port.
• Broadcast and multicast flooding are deliberately left on (bcast_flood / mcast_flood), so DHCP and ND still work. Guests can therefore still observe broadcast ARP from the uplink; suppressing that (neigh_suppress) is a separate change.

Testing

• go vet ./lib/network/ on linux, and GOOS=darwin go vet ./lib/network/ for the stub — both clean.
• go test ./lib/network/ passes.
• Exercised against a real bridge. TestHardenIsolatedPortOnRealBridge and TestHardenIsolatedPortLeavesPortAloneOnBadMAC create an actual bridge and enslaved TAP and assert the resulting port state, so the netlink requests themselves are covered rather than just the entry builder. They skip when not root, following the existing convention for privileged tests in this repo. Run as root on kernel 6.12:
  • flood off / learning off read back via LinkGetProtinfo
  • the guest MAC present in NeighList(tap, AF_BRIDGE) as NUD_PERMANENT
  • on an unparseable MAC, flood on / learning on — the port is untouched
  • both tests clean up their links, verified with ip -br link afterwards
• TestGuestFDBEntry / TestGuestFDBEntryRejectsBadMAC still cover the pure entry builder.
• go build ./... reports three //go:embed errors for downloaded binaries; identical on main (pre-existing, unrelated).

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 7e52be6. Configure here.}

[cursor]

FDB entry marks guest MAC local

High Severity

guestFDBEntry sets NUD_PERMANENT, which the kernel maps to BR_FDB_LOCAL. Frames for the guest MAC are passed up to the host instead of forwarded to the TAP. With unicast flooding disabled, isolated guests lose inbound unicast entirely.

 

^{Reviewed by Cursor Bugbot for commit 7e52be6. Configure here.}

[sjmiller609]

Requesting more information and validation of this change:

• before/after benchmarks: test latency in a development hypeman server deployed from this code version (e.g. working on the deft server). try this skill /benchmark-hypeman-fork, which is the most-critical path for our platform, but also please test normal creation and restore. compare latency and failure rates, including concurrent operations. Post in this PR in a comment or similar to know latency doesn't suffer majorly from this.
• security proof or documented what you tried before / after: either a test or comment showing the practical issue demonstrated in the before case and resolved in the after case.
• staging QA: deploy the change to staging hypeman via our CI and validate it there, ensuring normal platform behavior. I think it would be conspicuously broken in the case of not working. Rollback is safe, i.e. we can undo this change in staging and so long as the associated VMs are deleted, then the change is cleanly reverted. Document in this PR what was validated.