avahi-daemon segfaults if all services are browsed and Bosch Home Connect responds

[scrool]

I have cooktop/hob BOSCH PXY675JW1E connected on my local network. Apparently it responds to mDNS queries. If I browse for all services avahi daemon segfaults.

1. I start daemon in one terminal:

$ sudo avahi-daemon/avahi-daemon -f ./avahi-daemon/avahi-daemon.conf
Found user 'avahi' (UID 70) and group 'avahi' (GID 70).
Successfully dropped root privileges.
lt-avahi-daemon 0.7 starting up.
Failed to read /usr/local/etc/avahi/services.
*** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
New relevant interface virbr0.IPv4 for mDNS.
Joining mDNS multicast group on interface wlp3s0.IPv6 with address fdee:2bec:(not-so-important):5209.
New relevant interface wlp3s0.IPv6 for mDNS.
Joining mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.1.169.
New relevant interface wlp3s0.IPv4 for mDNS.
Network interface enumeration completed.
Registering new address record for 192.168.122.1 on virbr0.IPv4.
Registering new address record for fdee:2bec:(not-so-important):5209 on wlp3s0.*.
Registering new address record for fdee:2bec:f6a::aa3 on wlp3s0.*.
Registering new address record for 192.168.1.169 on wlp3s0.IPv4.
Server startup complete. Host name is ramona.local. Local service cookie is 822861744.

When I browse in other terminal:

$ avahi-browse -a
avahi_service_browser_new() failed: Invalid service type

daemon crashes:

[1]    16661 segmentation fault  sudo avahi-daemon/avahi-daemon -f ./avahi-daemon/avahi-daemon.conf

2. On the other hand if I ask for specific service type:

$ avahi-browse -v _services._dns-sd._udp
Server version: avahi 0.7; Host name: ramona.local
E Ifce Prot Name                                          Type                 Domain
: Cache exhausted
+ wlp3s0 IPv4 Hob BOSCH PXY675JW1E                          _homeconnect._tcp    local
+ wlp3s0 IPv6 Hob BOSCH PXY675JW1E                          _homeconnect._tcp    local
+ wlp3s0 IPv4 _http                                         _tcp                 local
+ wlp3s0 IPv4 _nfs                                          _tcp                 local
+ wlp3s0 IPv4 _smb                                          _tcp                 local
+ wlp3s0 IPv4 _ssh                                          _tcp                 local
+ wlp3s0 IPv4 _sftp-ssh                                     _tcp                 local
: All for now
^CGot SIGINT, quitting.

I get results just fine.

I guess it is because hob provides incorrect (?) PTR records for _services._dns-sd._udp.local, like this:

_services._dns-sd._udp.local	IN	PTR Hob\032BOSCH\032PXY675JW1E._homeconnect._tcp.local ; ttl=120

and code that parses rdata expects it to start with underscore. I'm not sure if I read https://tools.ietf.org/html/rfc6763#section-9 correctly though.

For completeness I use latest master to this date pointing to:

commit 4a5454fdf7e012b88904c2bd5423e5ccdf2ede92
Merge: 9c3fce3 6a62d99
Author: Trent Lloyd <[email protected]>
Date:   Tue May 7 03:24:15 2019 +0200

I ran configure like this:

$ ./configure --disable-qt4 --disable-qt5 --disable-gtk --disable-gtk3 --disable-python --disable-pygobject --disable-python-dbus --disable-mono --disable-monodoc --disable-doxygen-doc --disable-doxygen-dot --disable-doxygen-xml --disable-doxygen-html --disable-manpages --disable-xmltoman

And all those on Fedora release 30.

[lathiat]

Thanks for the report. This looks like a bug I will look into this.

[ferbar]

I think this is a dup of #212

[khwaaj]

I ran into this with a BOSCH device as well today. Adding something like the patch below to drop the incorrectly provided name during parsing seems to work around the issue.

diff --git a/avahi-common/domain.c b/avahi-common/domain.c
index 3b1ab68..83b7f44 100644
--- a/avahi-common/domain.c
+++ b/avahi-common/domain.c
@@ -546,7 +546,9 @@ int avahi_service_name_split(const char *p, char *name, size_t name_size, char *
                         return AVAHI_ERR_NO_MEMORY;
 
                     break;
-                }
+                } else if (type_empty && *p)
+                    /* This is likely an incorrectly provided name, just drop it */
+                    break;
 
                 state = DOMAIN;
                 /* fall through */

[playaspec]

I've been trying to solve the issue this patch attempts to address literally for YEARS. At least since 2016.

I have applied this patch to the most recent source (0.8), purged previous versions from my system, built and installed.

It does not seem to address the issue of avahi-browse -a returning the error avahi_service_browser_new() failed: Invalid service type, as it still occurs. It would be highly useful for there to be logging of the malformed/illegal value, along with the IP of the offending device so it can be tracked down and smashed into tiny pieces.

[sur5r]

It would be highly useful for there to be logging of the malformed/illegal value, along with the IP of the offending device so it can be tracked down and smashed into tiny pieces.

I very much second this. At least with --debug it should log something.

[evverx]

Assuming it's still reproducible can anyone attach a symbolized backtrace showing where avahi-daemon segfaults?

[scrool]

Assuming it's still reproducible can anyone attach a symbolized backtrace showing where avahi-daemon segfaults?

With HEAD on latest master (335c7bb8c626468925f5b13a86805e1a63f967f6) I have tried to reproduce this and daemon no longer segfaults. Instead following is printed in verbose mode:

dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=GetAPIVersion
dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=GetState
dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceTypeBrowserNew
dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew
dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew
dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew
dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew
dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew
dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew
dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=ServiceBrowserNew
dbus-util.c: Responding error 'Invalid service type' (-11)
dbus-protocol.c: client :1.196 vanished.

and avahi-browse responds the same way as before.

Since my issue was with segfault I'm going to close this issue.

[evverx]

@scrool good to know. Thanks!

Since there haven't been a lot of commits lately I'm not sure what could have fixed it (in theory it could be that the devices got updated and no longer send exactly the same packets) but just to make sure I fuzzed avahi_service_name_split with all sorts of strings and based on my experiments it can't be crashed either (not this way at least). Having said that if anyone else can still reproduce the segfault it would be great if a symbolized backtrace could be attached.

avahi-browse -a is tracked https://github.com/lathiat/avahi/issues/212 as far as I can see.

[scrool]

Since there haven't been a lot of commits lately I'm not sure what could have fixed it (in theory it could be that the devices got updated and no longer send exactly the same packets) but just to make sure I fuzzed avahi_service_name_split with all sorts of strings and based on my experiments it can't be crashed either (not this way at least).

With bisect I ended up with 4a6d6cc962d2c03cb5b40c02b92f04a8b1128009 to be first good commit. I hope I got it correctly - with merges of multiple commits at once I tried couple of those parents.

Having said that if anyone else can still reproduce the segfault it would be great if a symbolized backtrace could be attached.

(gdb) backtrace
#0  0x0000000000415119 in dbus_delay_ServiceBrowserInfo_service_browser_start (t=0x456000, userdata=0x0) at dbus-protocol.c:1056
#1  0x00007ffff7fb732d in timeout_callback (t=0x456000) at simple-watch.c:447
#2  0x00007ffff7fb773e in avahi_simple_poll_dispatch (s=0x437d10) at simple-watch.c:570
#3  0x00007ffff7fb78b5 in avahi_simple_poll_iterate (s=0x437d10, timeout=-1) at simple-watch.c:605
#4  0x0000000000409d40 in run_server (c=0x428aa0 <config>) at main.c:1256
#5  0x000000000040a9ba in main (argc=2, argv=0x7fffffffe568) at main.c:1674
(gdb) 

I hope that's what you meant. This was with HEAD on 426a5a5f439649d8664bf9968998fb39ec49e02c.

[evverx]

Got it. Thanks! To judge from the backtrace it seems dbus_delay_ServiceBrowserInfo_service_browser_start tried to dereference a NULL pointer to ServiceBrowserInfo and crashed so it seems avahi_service_name_split wasn't the culprit in the sense that it didn't crash avahi directly. All in all it seems to be a timing issue where NULL pointers are passed around and dereferenced when avahi gets service names like that and I'm not sure it's fixed. @scrool could you try running something like

 while :; do avahi-browse -at; done

with the master branch for some time to make it more likely to trigger that segfault if it's still there?

[scrool]

@scrool could you try running something like

 while :; do avahi-browse -at; done

with the master branch for some time to make it more likely to trigger that segfault if it's still there?

I got this running for an hour and it didn't trigger segfault. I could run it for some more time if needed.

[evverx]

@scrool I set up a bogus responder that should be able to imitate those devices hopefully. It's been running for an hour as well and avahi hasn't crashed yet. I think if it can survive the weekend with that bogus responder it should be safe to say that it more or less works. Now that the backtrace is attached I think it should be easier to revive this issue should anyone else run into it. Thanks again!

[evverx]

Looks like It was fixed in https://github.com/lathiat/avahi/commit/95d93a5969bfeae813c5ed9066a577cfad9b3e20.

Just to expand that backtrace a bit without that commit avahi crashes reliably as soon as the bogus responder pops up with

==3579273==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040000069a0 at pc 0x000000429be9 bp 0x7fffba0dcd10 sp 0x7fffba0dcd08
READ of size 8 at 0x6040000069a0 thread T0 (avahi-daemon)
    #0 0x429be8 in dbus_delay_ServiceBrowserInfo_service_browser_start /home/vagrant/avahi/avahi-daemon/dbus-protocol.c:1056
    #1 0x7f10b33ed9e7 in timeout_callback /home/vagrant/avahi/avahi-common/simple-watch.c:447
    #2 0x7f10b33f23ae in avahi_simple_poll_dispatch /home/vagrant/avahi/avahi-common/simple-watch.c:570
    #3 0x7f10b33f297b in avahi_simple_poll_iterate /home/vagrant/avahi/avahi-common/simple-watch.c:605
    #4 0x41020e in run_server /home/vagrant/avahi/avahi-daemon/main.c:1256
    #5 0x41020e in main /home/vagrant/avahi/avahi-daemon/main.c:1674
    #6 0x7f10b1c2950f in __libc_start_call_main (/lib64/libc.so.6+0x2950f)
    #7 0x7f10b1c295c8 in __libc_start_main_impl (/lib64/libc.so.6+0x295c8)
    #8 0x407324 in _start (/home/vagrant/avahi/avahi-daemon/.libs/avahi-daemon+0x407324)

0x6040000069a0 is located 16 bytes inside of 48-byte region [0x604000006990,0x6040000069c0)
freed by thread T0 (avahi-daemon) here:
    #0 0x7f10b2cb9388 in __interceptor_free.part.0 (/lib64/libasan.so.8+0xb9388)
    #1 0x7f10b33e2c2e in avahi_free /home/vagrant/avahi/avahi-common/malloc.c:138
    #2 0x4401f5 in avahi_dbus_service_browser_free /home/vagrant/avahi/avahi-daemon/dbus-service-browser.c:50
    #3 0x428b7b in client_free /home/vagrant/avahi/avahi-daemon/dbus-protocol.c:96
    #4 0x42b47b in msg_signal_filter_impl /home/vagrant/avahi/avahi-daemon/dbus-protocol.c:235
    #5 0x7f10b3344a40 in dbus_connection_dispatch (/lib64/libdbus-1.so.3+0x1ca40)

previously allocated by thread T0 (avahi-daemon) here:
    #0 0x7f10b2cba6af in __interceptor_malloc (/lib64/libasan.so.8+0xba6af)
    #1 0x7f10b33e29d3 in xmalloc /home/vagrant/avahi/avahi-common/malloc.c:68
    #2 0x7f10b33e29d3 in avahi_malloc /home/vagrant/avahi/avahi-common/malloc.c:107
    #3 0x42cfc4 in avahi_new_internal ../avahi-common/malloc.h:50
    #4 0x42cfc4 in dbus_prepare_service_browser_object /home/vagrant/avahi/avahi-daemon/dbus-protocol.c:599
    #5 0x4341ae in dbus_select_browser /home/vagrant/avahi/avahi-daemon/dbus-protocol.c:1084
    #6 0x4346c0 in msg_server_impl /home/vagrant/avahi/avahi-daemon/dbus-protocol.c:1173
    #7 0x7f10b3344d10 in dbus_connection_dispatch (/lib64/libdbus-1.so.3+0x1cd10)

SUMMARY: AddressSanitizer: heap-use-after-free /home/vagrant/avahi/avahi-daemon/dbus-protocol.c:1056 in dbus_delay_ServiceBrowserInfo_service_browser_start
Shadow bytes around the buggy address:
  0x0c087fff8ce0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8cf0: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8d00: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8d10: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8d20: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
=>0x0c087fff8d30: fa fa fd fd[fd]fd fd fd fa fa fd fd fd fd fd fd
  0x0c087fff8d40: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8d50: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8d60: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8d70: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8d80: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3579273==ABORTING