BACnet router demo overflow
Brought to you by:
skarg
I get a buffer overflow sometimes on the router, but only sometimes, and with no changes between successful and unsuccessful runs.
Is it me? I wondered if it was happening because of the loopback, but changing it to be another net on eno1 doesn't resolve it.
sidenote: I've observed another issue with the router demo sometimes endlessly repeating stuff between networks, maybe when I had different interfaces set to the same BACNET port, but that was with a complicated GNS3 network bridged out to real devices, so it probably isn't worth it's own report until I reproduce it in a simpler environment.
Back to this bug report, details:
The config:
ports = ( { device_type = "bip"; device = "eno1"; port = 47808; network = 1; }, { device_type = "bip"; device = "lo"; port = 47809; network = 4; } );
The overflows:
$ ./router -c router.cfg I am router opt = c dev_type = bip dev_type = bip cmd file parse success Initializing... Interface: eno1 IP Address: 192.168.168.128 IP Broadcast Address: 192.168.168.255 UDP Port: 0xBAC0 [47808] Interface: lo IP Address: 127.0.0.1 IP Broadcast Address: 0.0.0.0 UDP Port: 0xBAC1 [47809] send to 192.168.168.255 *** buffer overflow detected ***: ./router terminated Aborted (core dumped)
$ ./router -c router.cfg I am router opt = c dev_type = bip dev_type = bip cmd file parse success Initializing... Interface: eno1 Interface: lo IP Address: 127.0.0.1 IP Broadcast Address: 0.0.0.0 UDP Port: 0xBAC1 [47809] IP Address: 192.168.168.128 IP Broadcast Address: 192.168.168.255 UDP Port: 0xBAC0 [47808] send to 192.168.168.255 *** buffer overflow detected ***: ./router terminated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f9b0d9e67e5] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f9b0da8756c] send to 0.0.0.0 *** buffer overflow detected ***: ./router terminated ./router[0x407c69] /lib/x86_64-linux-gnu/libc.so.6./router[0x407ff4] /lib/x86_64-linux-gnu/libc.so.6(+0x116570)[0x7f9b0da85570] 00400000-0040d000 r-xp 00000000 08:04 7083875 /home/scada/builds/bacnet-stack/bin/router 0060c000-0060d000 r--p 0000c000 08:04 7083875 /home/scada/builds/bacnet-stack/bin/router 0060d000-0060e000 rw-p 0000d000 08:04 7083875 /home/scada/builds/bacnet-stack/bin/router 0060e000-00610000 rw-p 00000000 00:00 0 021c7000-021e8000 rw-p 00000000 00:00 0 [heap] 7f9b00000000-7f9b00021000 rw-p 00000000 00:00 0 7f9b00021000-7f9b04000000 ---p 00000000 00:00 0 7f9b08000000-7f9b08021000 rw-p 00000000 00:00 0 7f9b08021000-7f9b0c000000 ---p 00000000 00:00 0 7f9b0c025000-7f9b0c03b000 r-xp 00000000 08:04 5116556 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f9b0c03b000-7f9b0c23a000 ---p 00016000 08:04 5116556 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f9b0c23a000-7f9b0c23b000 rw-p 00015000 08:04 5116556 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f9b0c23b000-7f9b0c23c000 ---p 00000000 00:00 0 7f9b0c23c000-7f9b0ca3c000 rw-p 00000000 00:00 0 7f9b0ca3c000-7f9b0ca3d000 ---p 00000000 00:00 0 7f9b0ca3d000-7f9b0d23d000 rw-p 00000000 00:00 0 7f9b0d23d000-7f9b0d248000 r-xp 00000000 08:04 5637266 /usr/lib/x86_64-linux-gnu/libconfig.so.9.2.0 7f9b0d248000-7f9b0d447000 ---p 0000b000 08:04 5637266 /usr/lib/x86_64-linux-gnu/libconfig.so.9.2.0 7f9b0d447000-7f9b0d448000 r--p 0000a000 08:04 5637266 /usr/lib/x86_64-linux-gnu/libconfig.so.9.2.0 7f9b0d448000-7f9b0d449000 rw-p 0000b000 08:04 5637266 /usr/lib/x86_64-linux-gnu/libconfig.so.9.2.0 7f9b0d449000-7f9b0d461000 r-xp 00000000 08:04 5123297 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f9b0d461000-7f9b0d660000 ---p 00018000 08:04 5123297 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f9b0d660000-7f9b0d661000 r--p 00017000 08:04 5123297 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f9b0d661000-7f9b0d662000 rw-p 00018000 08:04 /lib/x86_64-linux-gnu/libc.so.6(cloneAborted (core dumped)
Anonymous
I verified this still happens on HEAD. Not sure if this router has gotten a lot of love; however it seems to be because the dnet list is never initialized correctly. I thought I remember some linuxes changing the default malloc() behavior to randomize the pages instead of zeroing them to prevent use-after-free holes. In any case, this would be safer (and seems to fix it for me).
Merged pull request - thank you, Stephen Dawson-Haggerty!