Hii Laszlo, sorry for not responding earlier. We have put this report in our internal issues and are still investigating it. We will let you know if there is more information needed. Thanks a lot for the report, David David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o. On 7/6/26 16:36, Laszlo Király via Bird-users wrote:
Hello BIRD maintainers,
I would like to report a memory leak in BIRD3. After uplifting from v2 we can see a persistent memory consumption increase in bird daemon. Running bird daemon by Valgrind turned out that the leak is in BIRD3's 'domain_new' called from 'cli_command'. Every birdc interaction leaks one 80-byte domain object.
==53== 248,160 bytes in 3,102 blocks are definitely lost in loss record 204 of 204 ==53== at 0x48419B4: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==53== by 0x4990D1: bird_xmalloc (xmalloc.c:46) ==53== by 0x584514: domain_new (domain.c:72) ==53== by 0x499438: obstacle_target_init (obstacle.h:57) ==53== by 0x499BCD: cli_command (cli.c:258) ==53== by 0x499D48: cli_event (cli.c:294) ==53== by 0x47CCEE: ev_run_list_limited (event.c:336) ==53== by 0x572FFE: io_loop (io.c:2641) ==53== by 0x5843CF: main (main.c:1114) ==53== ==53== LEAK SUMMARY: ==53== definitely lost: 248,160 bytes in 3,102 blocks ==53== indirectly lost: 0 bytes in 0 blocks ==53== possibly lost: 576 bytes in 2 blocks ==53== still reachable: 481,941 bytes in 3,818 blocks ==53== suppressed: 0 bytes in 0 blocks ==53== ==53== For lists of detected and suppressed errors, rerun with: -s ==53== ERROR SUMMARY: 34 errors from 12 contexts (suppressed: 0 from 0)
Not familiar with BIRD source code, just guessing that domain_free() needs to be called when the CLI command's obstacle target completes. BGP+BFD routing was configured and'birdc configure/birdc show'commands are called frequently by our monitor application and the leak is proportional to CLI invocation count. Let me know if any additional detail is needed.
---
Additionally, 'use-after-free errors' can be seen in the log: Invalid read of size 8 at bgp_listen_free (bgp.c:416) Address is inside a block that was already free'd by pool_free
This happens during BGP protocol shutdown (proto_cleanup > proto_loop_stopped > pool_free > bgp_listen_free). The BGP listen socket structure is accessed after its containing pool is freed. This is a BIRD3 bug in protocol teardown ordering, not related to the memory leak but indicates a use-after-free that could cause crashes.
Best Regards, Laszlo Kiraly