Fw: [oss-security] BIRD/BIRD2: stack buffer overflow in BGP AS_PATH mask matching, CVE pending

[Maria Matejka]

Hello Bruce,

On Tue, Jun 02, 2026 at 07:11:12PM +0100, Bruce Duncan wrote:

> FYI, since I didn't see anything about this, I thought operators might
> want to be aware that a "vulnerability" has been disclosed on the
> oss-security list today, and this might cause managers/auditors to ask
> you probing questions.

Thank you for the heads-up!

We already know about that. We actually issued an advisory together with
the last release, and anybody following that advisory would be
completely safe regarding this report. To put that straight, you should
always check for absurdly long AS Paths, and that sole thing would
prevent the problem.

Below, I have some notes to the report.

> [...]
> A sufficiently
> large or specially crafted AS_PATH can exceed a fixed-size stack buffer
> used during matching.

It needs extended messages to be on.

> [...]
> Affected versions

It's basically in all versions.

> [...]
> Fixed version
> 
> No fixed version is available at the time of this disclosure.

Will be soon.

> [...]
> 
> - The target configuration must evaluate the received AS_PATH with an
>   AS path mask, for example by using a filter expression such as:
> 
>     bgp_path ~ [= ... =]

This is true.

> - The issue is easier to trigger when BGP Extended Messages are enabled,
>   because larger UPDATE messages allow larger path attributes.

The issue is impossible to trigger without extended messages.

> - Confederation AS_PATH segments may make simple length-based
>   mitigations unreliable, depending on how the local filter checks
>   AS_PATH length before path mask evaluation.

Confederations are considered invalid unless you are in a confederation.

> Mitigation
> ==========
> 
> Until an upstream fix is available, operators should consider the
> following mitigations:
> 
> - Avoid applying AS path mask matching to routes received from
>   untrusted or semi-trusted BGP peers.

For paths shorter than 2048 ASNs, this is safe.

> - Avoid using filters such as:
> 
>     bgp_path ~ [= ... =]
> 
>   on untrusted input unless AS_PATH size and structure are strictly
>   bounded before evaluation.

This is the same as before.

> - Do not enable BGP Extended Messages for untrusted peers unless they
>   are required.

This is a good idea anyway.

> - Reject unusually large AS_PATH attributes before any AS path mask
>   matching is performed.

This is a basic network hygiene.

> - Be careful with simple bgp_path.len based checks, as confederation
>   AS_PATH segments may not be accounted for in the same way as they are
>   expanded or processed during matching.

Confederations should be considered trusted enough to not expect
malicious actors from there.

> - Restrict BGP sessions to trusted peers.

Well, you always need to know the other side at least a bit.

> [...]
> The issue was reported to CZ.NIC on 2026-05-02.

This is true.

> On 2026-05-24, CZ.NIC stated that they do not currently plan to fix
> the issue.

This is false. We explicitly stated that we do not have a specific
timeline, which was being insisted on by the reporter. We never planned
to not fix the issue.

Also, we've been, in that time, swamped by other LLM reports and also
bugs with a real impact, let aside finalizing the VXLAN/EVPN
implementation to clean our table.

> Discovered by Bakabaka_9.

Discovered by at least five different reporters over the course of
several weeks.

We'll put out more information on this as soon as we have everything
consolidated.

Thank you for your understanding.  
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260603/1ec78cbc/attachment.htm>