Buffer over-read vulnerability in the dtlssha256update function in Contiki-NG tinyDTLS through master branch 53a0d97 allows remote attackers to cause a denial of service via crafted data packet.

An issue was discovered in Contiki-NG tinyDTLS through master branch 53a0d97. DTLS servers mishandle the early use of a large epoch number. This vulnerability allows remote attackers to cause a denial of service and false-positive packet drops.

In Microchip MPLAB Net 3.6.1, TCP ISNs are improperly random.

In Silicon Labs uC/TCP-IP 3.6.0, TCP ISNs are improperly random.

In Oryx CycloneTCP 1.9.6, TCP ISNs are improperly random.

In Contiki 4.5, TCP ISNs are improperly random.

In FNET 4.6.3, TCP ISNs are improperly random.

In PicoTCP 1.7.0, TCP ISNs are improperly random.

An issue was discovered in Ethernut Nut/OS 5.1. The code that generates Initial Sequence Numbers (ISNs) for TCP connections derives the ISN from an insufficiently random source. As a result, an attacker may be able to determine the ISN of current and future TCP connections and either hijack existing ones or spoof future ones. While the ISN generator seems to adhere to RFC 793 (where a global 32-bit counter is incremented roughly every 4 microseconds), proper ISN generation should aim to follow at least the specifications outlined in RFC 6528.

In SIMATIC MV400 family versions prior to v7.0.6, the ISN generator is initialized with a constant value and has constant increments. An attacker could predict and hijack TCP sessions.

An issue was discovered in uIP through 1.0, as used in Contiki and Contiki-NG. Domain name parsing lacks bounds checks, allowing an attacker to corrupt memory with crafted DNS packets.

An issue was discovered in the IPv6 stack in Contiki through 3.0. There are inconsistent checks for IPv6 header extension lengths. This leads to Denial-of-Service and potential Remote Code Execution via a crafted ICMPv6 echo packet.

An issue was discovered in the IPv6 stack in Contiki through 3.0. There is an insufficient check for the IPv6 header length. This leads to Denial-of-Service and potential Remote Code Execution via a crafted ICMPv6 echo packet.

An issue was discovered in the DNS implementation in Ethernut in Nut/OS 5.1. The length byte of a domain name in a DNS query/response is not checked, and is used for internal memory operations. This may lead to successful Denial-of-Service, and possibly Remote Code Execution.

An issue was discovered in the DNS implementation in Ethernut in Nut/OS 5.1. The number of DNS queries/responses (set in a DNS header) is not checked against the data present. This may lead to successful Denial-of-Service, and possibly Remote Code Execution.

An issue was discovered in the DNS implementation in Ethernut in Nut/OS 5.1. The DNS response data length is not checked (it can be set to an arbitrary value from a packet). This may lead to successful Denial-of-Service, and possibly Remote Code Execution.

An issue was discovered in the DNS implementation in Ethernut in Nut/OS 5.1. There is no check on whether a domain name has '\0' termination. This may lead to successful Denial-of-Service, and possibly Remote Code Execution.

An issue was discovered in FNET through 4.6.4. The code for processing resource records in mDNS queries doesn't check for proper '\0' termination of the resource record name string, leading to an out-of-bounds read, and potentially causing information leak or Denial-or-Service.

An issue was discovered in picoTCP and picoTCP-NG through 1.7.0. The TCP input data processing function in picotcp.c does not validate the length of incoming TCP packets, which leads to an out-of-bounds read when assembling received packets into a data segment, eventually causing Denial-of-Service or an information leak.

An issue was discovered in picoTCP and picoTCP-NG through 1.7.0. The code that processes DNS responses in picomdnshandledataasanswersgeneric() in picomdns.c does not check whether the number of answers/responses specified in a DNS packet header corresponds to the response data available in the packet, leading to an out-of-bounds read, invalid pointer dereference, and Denial-of-Service.

An issue was discovered in picoTCP and picoTCP-NG through 1.7.0. The DNS domain name record decompression functionality in picodnsdecompressname() in picodnscommon.c does not validate the compression pointer offset values with respect to the actual data present in a DNS response packet, causing out-of-bounds reads that lead to Denial-of-Service.

An issue was discovered in picoTCP through 1.7.0. The DNS domain name record decompression functionality in picodnsdecompressname() in picodnscommon.c does not validate the compression pointer offset values with respect to the actual data present in a DNS response packet, causing out-of-bounds writes that lead to Denial-of-Service and Remote Code Execution.

An issue was discovered in picoTCP and picoTCP-NG through 1.7.0. When an unsupported TCP option with zero length is provided in an incoming TCP packet, it is possible to cause a Denial-of-Service by achieving an infinite loop in the code that parses TCP options, aka tcpparseoptions() in picotcp.c.

An issue was discovered in Contiki through 3.0 and Contiki-NG through 4.5. The code for parsing Type A domain name answers in ip64-dns64.c doesn't verify whether the address in the answer's length is sane. Therefore, when copying an address of an arbitrary length, a buffer overflow can occur. This bug can be exploited whenever NAT64 is enabled.

The code that processes DNS responses in uIP through 1.0, as used in Contiki and Contiki-NG, does not check whether the number of responses specified in the DNS packet header corresponds to the response data available in the DNS packet, leading to an out-of-bounds read and Denial-of-Service in resolv.c.

An issue was discovered in FNET through 4.6.4. The code that initializes the DNS client interface structure does not set sufficiently random transaction IDs (they are always set to 1 in fnetdnspoll in fnetdns.c). This significantly simplifies DNS cache poisoning attacks.

An issue was discovered in FNET through 4.6.4. The code for IPv6 fragment reassembly tries to access a previous fragment starting from a network incoming fragment that still doesn't have a reference to the previous one (which supposedly resides in the reassembly list). When faced with an incoming fragment that belongs to a non-empty fragment list, IPv6 reassembly must check that there are no empty holes between the fragments: this leads to an uninitialized pointer dereference in fnetip6reassembly in fnetip6.c, and causes Denial-of-Service.

An issue was discovered in FNET through 4.6.4. The code for processing the hop-by-hop header (in the IPv6 extension headers) doesn't check for a valid length of an extension header, and therefore an out-of-bounds read can occur in fnetip6extheaderhandleroptions in fnetip6.c, leading to Denial-of-Service.

An issue was discovered in FNET through 4.6.4. The code for processing the hostname from an LLMNR request doesn't check for '\0' termination. Therefore, the deduced length of the hostname doesn't reflect the correct length of the actual data. This may lead to Information Disclosure in fnetllmnrpoll in fnetllmnr.c during a response to a malicious request of the DNS class IN.

An issue was discovered in picoTCP 1.7.0. The code for processing the IPv6 destination options does not check for a valid length of the destination options header. This results in an Out-of-Bounds Read, and, depending on the memory protection mechanism, this may result in Denial-of-Service in picoipv6processdestopt() in picoipv6.c.