There are 4 open security issues in bullseye.
commit 30c0619cff7e58c6753dd41cb86118bb94946c81
Author: Thomas Goirand <zigo@debian.org>
Date: Wed Nov 11 14:57:01 2026 +0100
Prefix our quilt patches with ovn-bgp-2-host_
Rename the four patches written for the BGP-2-the-host campaign so
their filenames carry the campaign prefix (underscore before the
topic), and update debian/patches/series and the changelog bullet
references accordingly. No patch content is changed.
commit 10dc78b00e570069f55f776f70929ae5ecc702d2
Author: Thomas Goirand <zigo@debian.org>
Date: Wed Nov 11 14:43:15 2026 +0100
Refreshed segment-notifier patch to remove hunk offsets
fix-test-segment-notifier-batch-wait.patch applied with two 20-line
hunk offsets; dpkg-source tolerates offsets but the quilt hygiene rule
requires a queue that applies without any warnings. Refresh only moves
the hunks: the applied content is identical.
commit f74c819ef3c7b554a46b2f2743317ffa9c93c393
Author: Thomas Goirand <zigo@debian.org>
Date: Wed Nov 11 14:43:08 2026 +0100
Added patch limiting BGP learned-route LRP exposure
ovn-controller attaches learned routes to every logical router port of
the dynamic-routing routers except those carrying the
dynamic-routing-no-learning option. Upstream only stamps that option on
the chassis-router-side LRP of the chassis/main peering, leaving the
main router's interconnect LRP and the chassis routers' provider
network LRPs learning. Learned routes landing there render the provider
subnet as ECMP with an unreachable next-hop, flapping the floating IP
return path with roughly 50% packet loss.
Stamp both LRP families with dynamic-routing-no-learning so learned
routes only ever attach to the main router's chassis peering LRPs,
which carry the neutron-bgp-lrp-to-chassis-router external ID and are
the ports the static MAC binding seeding fix operates on. Both are
re-asserted at every reconciler full sync, so existing deployments
converge on agent restart without recreating ports.
commit f8e04983a2c373afb73ccb107bb3c57156e61e8b
Author: Thomas Goirand <zigo@debian.org>
Date: Tue Nov 10 21:06:51 2026 +0100
Added VIF re-attach extension patch for OVN agent
New quilt patch: a "vif-reattach" OVN agent extension, always on,
which re-converges the OVS plugging state of VM ports from the
Port_Binding and OVS lifecycle events. When the OVS Interface row of
a bound VM port goes missing (an OVS database restore, a wiped
bridge, as seen during the OpenVSwitch 4.0 upgrade incident),
ovn-controller waits forever for the interface and the VM stays
unreachable; the extension re-attaches the tap immediately on the OVS
Interface deletion and integration bridge re-creation events,
restores lost external_ids (iface-id, attached-macs, attached-ips)
on port updates, and cleans up leftover rows on unbind/delete.
Guards keep it out of other components' way: only VM Port_Bindings,
no vif-plug-type ports (SR-IOV representors), no interference with
live migrations (additional_chassis), interface type system-only for
cleanup, iface-id match for every mutation, and creation only when
the kernel device still exists (freshly bound ports stay with
os-vif). No periodic reconciliation, purely event-driven; converges
on the initial SB dump so the agent self-heals at startup.
Includes the stevedore entry point, 32 unit tests and 4 functional
tests on the OVN agent fixture.
commit 0dfa941589eed34aa2bd3c38789f535d250a6113
Author: Thomas Goirand <zigo@debian.org>
Date: Tue Nov 10 20:22:29 2026 +0100
Added patch seeding static MAC bindings for BGP
New quilt patch: the BGP agent extension now watches the SB
Learned_Route table (added to the agent's sb_idl table filter, with
Static_MAC_Binding and Datapath_Binding) and seeds a
Static_MAC_Binding row with override_dynamic_mac=true for every
learned route attached to a BGP main router peering LRP, resolving
the learned nexthop (the fabric peer's link-local address, imported
verbatim by ovn-controller) to the chassis router's peering LRP MAC,
derived deterministically from the peer LRP name. Without this, the
MAC binding lookup resolves dynamically to the fabric peer's own MAC,
which the peering link never delivers to, blackholing all traffic
coming from the BGP fabric on the BGP main router. Learned routes on
other routers' peerings are ignored.
Lab-verified on the OVN BGP dynamic-routing setup: this is the
"MAC_Binding flip + static pinning" recipe, made automatic.
commit 0814d59d49bb3518770b4906747c5c29c07fda77
Author: Thomas Goirand <zigo@debian.org>
Date: Tue Nov 10 20:07:38 2026 +0100
Added patch fixing BGP bridge patch port selection
The BGP chassis bridge's patch_port_ofport() returned the first patch
port found on the provider bridge, steering wire-side frames into the
wrong logical switch when the bridge carries multiple patch ports
(BGP localnet, provider network, interconnect localnet). The patch
port is now selected by the iface-id of its peer interface on the
integration bridge, which carries the localnet LSP name of the
per-chassis BGP logical switch.
Added patch fixing the BGP chassis bridge patch port selection when
the provider bridge carries multiple patch ports:
- fix-bgp-agent-wrong-patch-port.patch
Among the 15 debian patches available in version 2:29.0.0-9 of the package, we noticed the following issues:
Automatic checks made by the Debian l10n team found some issues with the translations contained in this package. You should check the l10n status report for more information.
Issues can be things such as missing translations, problematic translated strings, outdated PO files, unknown languages, etc.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/n/neutron.png){kind=link}