In ConnMan through 1.44, the lookup string in nsresolv in dnsproxy.c can be NULL or an empty string when the TC (Truncated) bit is set in a DNS response. This allows attackers to cause a denial of service (application crash) or possibly execute arbitrary code, because those lookup values lead to incorrect length calculations and incorrect memcpy operations.

In ConnMan through 1.44, parserr in dnsproxy.c has a memcpy length that depends on an RR RDLENGTH value, i.e., rdlen=ntohs(rr->rdlen) and memcpy(response+offset,end,rdlen) without a check for whether the sum of end and rdlen exceeds max. Consequently, rdlen may be larger than the amount of remaining packet data in the current state of parsing. Values of stack memory locations may be sent over the network in a response.

client.c in gdhcp in ConnMan through 1.41 could be used by network-adjacent attackers (operating a crafted DHCP server) to cause a stack-based buffer overflow and denial of service, terminating the connman process.

ConnMan 1.3 on Tizen continues to list the bluetooth service after offline mode has been enabled, which might allow remote attackers to obtain sensitive information via Bluetooth packets.

The loopback plug-in in ConnMan before 0.85 allows remote attackers to execute arbitrary commands via shell metacharacters in the (1) host name or (2) domain name in a DHCP reply.

ConnMan before 0.85 does not ensure that netlink messages originate from the kernel, which allows remote attackers to bypass intended access restrictions and cause a denial of service via a crafted netlink message.

Integer overflow in the dhcpv6getoption function in gdhcp/client.c in ConnMan before 0.85 allows remote attackers to cause a denial of service (infinite loop and crash) via an invalid length value in a DHCP packet.