In Contiki 3.0, Telnet option negotiation is mishandled. During negotiation between a server and a client, the server may fail to give the WILL/WONT or DO/DONT response for DO and WILL commands because of improper handling of exception condition, which leads to property violations and denial of service. Specifically, a server sometimes sends no response, because a fixed buffer space is available for all responses and that space may have been exhausted.
In Contiki 3.0, a buffer overflow in the Telnet service allows remote attackers to cause a denial of service because the ls command is mishandled when a directory has many files with long names.
In Contiki 3.0, a Telnet server that silently quits (before disconnection with clients) leads to connected clients entering an infinite loop and waiting forever, which may cause excessive CPU consumption.
In Contiki 3.0, potential nonterminating acknowledgment loops exist in the Telnet service. When the negotiated options are already disabled, servers still respond to DONT and WONT requests with WONT or DONT commands, which may lead to infinite acknowledgment loops, denial of service, and excessive CPU consumption.
An issue was discovered in Contiki through 3.0. When sending an ICMPv6 error message because of invalid extension header options in an incoming IPv6 packet, there is an attempt to remove the RPL extension headers. Because the packet length and the extension header length are unchecked (with respect to the available data) at this stage, and these variables are susceptible to integer underflow, it is possible to construct an invalid extension header that will cause memory corruption issues and lead to a Denial-of-Service condition. This is related to rpl-ext-header.c.
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 uIP 1.0, as used in Contiki 3.0 and other products. The code that parses incoming DNS packets does not validate that domain names present in the DNS responses have '\0' termination. This results in errors when calculating the offset of the pointer that jumps over domain name bytes in DNS response packets when a name lacks this termination, and eventually leads to dereferencing the pointer at an invalid/arbitrary address, within newdata() and parse_name() in resolv.c.
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 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.
An issue was discovered in uIP 1.0, as used in Contiki 3.0 and other products. When the Urgent flag is set in a TCP packet, and the stack is configured to ignore the urgent data, the stack attempts to use the value of the Urgent pointer bytes to separate the Urgent data from the normal data, by calculating the offset at which the normal data should be present in the global buffer. However, the length of this offset is not checked; therefore, for large values of the Urgent pointer bytes, the data pointer can point to memory that is way beyond the data buffer in uip_process in uip.c.