Vendor
6 published CVES affecting connman, from public sources (CVE.org, NVD, CISA KEV, FIRST EPSS, OSV).
Newest publication first
ConnMan through 2.0 has a stack-based buffer overflow via a DHCPv6 Reply message. This occurs in get_domains in gdhcp/client.c. It copies a fixed NS_MAXDNAME (1025) bytes from a DHCPv6 DOMAIN_LIST (option 24) value into a 1026-byte stack buffer dns_name regardless of the actual o...
In ConnMan through 1.44, the lookup string in ns_resolv 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 look...
In ConnMan through 1.44, parse_rr 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 t...
Integer overflow in the dhcpv6_get_option 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.
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.
Sources: CVE.org, NVD, CISA KEV, FIRST EPSS, OSV and public exploit-reference metadata. Product matching comes from the published CVE records. A proof-of-concept means public code exists; it is not evidence of exploitation.