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

Reply via email to