avahi_service_resolver_new causes recursion until stack is full about avahi

[lathiat]

That is uh, quite excellent. I tried just setting that hostname which wasn't enough to reproduce it for some super strange reason (that would have been nice :-)

But looking at the backtrace it looks like we're continuously looking up a cname. Do you have something on the network publishing aliases, like avahi-aliases or some code otherwise like https://github.com/airtonix/avahi-aliases/blob/master/avahi_aliases/bin/avahi-alias ?

I can reproduce it if I use that script to publish a CNAME for ourselves, triggers the recursion. So we should detect this recursive lookup and fail out.

[rlbartle]

Yes, there is also code that adds an alias.

[pemensik]

I think some kind to limited TTL should be used on CNAME follows. And lookup_handle_cname should create new lookup only if previous queries did not contain the current destination pointer. Not sure if we keep that history, I think we should. At least for cnames.

[pemensik]

It seems to me we just need to check l->cname_lookups for equal key. If we find it, then this lookup contains loop and we have to abort the search, call lookup_drop_cname to remove this search. Not sure how do we make search failed. Another check might ensure n->refs <= 1. But l->cname_lookups seems better place to check.

[evverx]

I revamped this issue in #501. @pemensik I wonder if RH assigned a CVE?

[pemensik]

I haven't found a vulnerability bug for avahi, which would sound similar. No CVE id for this issue it seems.