A vulnerability in ICMP Version 6 (ICMPv6) processing in Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause a slow system memory leak, which over time could lead to a denial of service (DoS) condition. This vulnerability is due to improper error handling when an IPv6-configured interface receives a specific type of ICMPv6 packet. An attacker could exploit this vulnerability by sending a sustained rate of crafted ICMPv6 packets to a local IPv6 address on a targeted device. A successful exploit could allow the attacker to cause a system memory leak in the ICMPv6 process on the device. As a result, the ICMPv6 process could run out of system memory and stop processing traffic. The device could then drop all ICMPv6 packets, causing traffic instability on the device. Restoring device functionality would require a device reboot.

An issue was discovered in OpenZFS through 2.0.3. When an NFS share is exported to IPv6 addresses via the sharenfs feature, there is a silent failure to parse the IPv6 address data, and access is allowed to everyone. IPv6 restrictions from the configuration are not applied.

An issue was discovered on FiberHome HG6245D devices through RP2613. By default, there are no firewall rules for IPv6 connectivity, exposing the internal management interfaces to the Internet.

In OpenWrt 19.07.x before 19.07.7, when IPv6 is used, a routing loop can occur that generates excessive network traffic between an affected device and its upstream ISP's router. This occurs when a link prefix route points to a point-to-point link, a destination IPv6 address belongs to the prefix and is not a local IPv6 address, and a router advertisement is received with at least one global unique IPv6 prefix for which the on-link flag is set. This affects the netifd and odhcp6c packages.

A vulnerability in the IPv6 traffic processing of Cisco IOS XR Software and Cisco NX-OS Software for certain Cisco devices could allow an unauthenticated, remote attacker to bypass an IPv6 access control list (ACL) that is configured for an interface of an affected device. The vulnerability is due to improper processing of IPv6 traffic that is sent through an affected device. An attacker could exploit this vulnerability by sending crafted IPv6 packets that traverse the affected device. A successful exploit could allow the attacker to access resources that would typically be protected by the interface ACL.

A vulnerability in the IPv6 protocol handling of the management interfaces of Cisco IOS XR Software could allow an unauthenticated, adjacent attacker to cause an IPv6 flood on the management interface network of an affected device. The vulnerability exists because the software incorrectly forwards IPv6 packets that have an IPv6 node-local multicast group address destination and are received on the management interfaces. An attacker could exploit this vulnerability by connecting to the same network as the management interfaces and injecting IPv6 packets that have an IPv6 node-local multicast group address destination. A successful exploit could allow the attacker to cause an IPv6 flood on the corresponding network. Depending on the number of Cisco IOS XR Software nodes on that network segment, exploitation could cause excessive network traffic, resulting in network degradation or a denial of service (DoS) condition.

A vulnerability in Juniper Networks Junos OS allows an attacker to cause a Denial of Service (DoS) to the device by sending certain crafted protocol packets from an adjacent device with invalid payloads to the device. These crafted packets, which should be discarded, are instead replicated and sent to the RE. Over time, a Denial of Service (DoS) occurs. Continued receipt of these crafted protocol packets will cause an extended Denial of Service (DoS) condition, which may cause wider traffic impact due to protocol flapping. An indication of compromise is to check "monitor interface traffic" on the ingress and egress port packet counts. For each ingress packet, two duplicate packets are seen on egress. This issue can be triggered by IPv4 and IPv6 packets. This issue affects all traffic through the device. This issue affects: Juniper Networks Junos OS: 14.1X53 versions prior to 14.1X53-D53 on EX4300, QFX3500, QFX5100, EX4600; 15.1 versions prior to 15.1R7-S6 on EX4300, QFX3500, QFX5100, EX4600; 16.1 versions prior to 16.1R7-S7 on EX4300, QFX5100, EX4600; 17.1 versions prior to 17.1R2-S11 on EX4300, QFX5100, EX4600; 17.1 versions prior to 117.1R3-S2 on EX4300; 17.2 versions prior to 17.2R1-S9 on EX4300; 17.2 versions prior to 17.2R3-S3 on EX4300, QFX5100, EX4600, QFX5110, QFX5200; 17.3 versions prior to 17.3R2-S5, 17.3R3-S7 on EX4300, QFX5100, EX4600, QFX5110, QFX5200; 17.4 versions prior to 17.4R2-S9, 17.4R3 on EX4300, QFX5100, EX4600, QFX5110, QFX5200; 18.1 versions prior to 18.1R3-S9 on EX4300, QFX5100, EX4600, QFX5110, QFX5200, QFX5210, EX2300, EX3400; 18.2 versions prior to 18.2R2-S7 on EX4300; 18.2 versions prior to 18.2R3-S3 on EX4300, QFX5100, EX4600, QFX5110, QFX5200, QFX5210, EX2300, EX3400; 18.3 versions prior to 18.3R2-S3, on EX4300; 18.3 versions prior to 18.3R1-S7, 18.3R3-S1 on EX4300, QFX5100, EX4600, QFX5110, QFX5200, QFX5210, QFX5120, EX4650, EX2300, EX3400; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3 on EX4300, QFX5100, EX4600, QFX5110, QFX5200, QFX5210, QFX5120, EX4650, EX2300, EX3400; 19.1 versions prior to 19.1R1-S4, 19.1R2-S1, 19.1R3 on EX4300, QFX5100, EX4600, QFX5110, QFX5200, QFX5210, QFX5120, EX4650, EX2300, EX3400; 19.2 versions prior to 19.2R1-S4, 19.2R2 on EX4300; 19.2 versions prior to 19.2R1-S3, 19.2R2 on QFX5100, EX4600, QFX5110, QFX5200, QFX5210, QFX5120, EX4650, EX2300, EX3400; 19.3 versions prior to 19.3R2-S1, 19.3R3 on EX4300; 19.3 versions prior to 19.3R1-S1, 19.3R2, 19.3R3 on QFX5100, EX4600, QFX5110, QFX5200, QFX5210, QFX5120, EX4650, EX2300, EX3400;

An improper interpretation conflict of certain data between certain software components within the Juniper Networks Junos OS devices does not allow certain traffic to pass through the device upon receipt from an ingress interface filtering certain specific types of traffic which is then being redirected to an egress interface on a different VLAN. This causes a Denial of Service (DoS) to those clients sending these particular types of traffic. Such traffic being sent by a client may appear genuine, but is non-standard in nature and should be considered as potentially malicious, and can be targeted to the device, or destined through it for the issue to occur. This issues affects IPv4 and IPv6 traffic. An indicator of compromise may be found by checking log files. You may find that traffic on the input interface has 100% of traffic flowing into the device, yet the egress interface shows 0 pps leaving the device. For example: [show interfaces "interface" statistics detail] Output between two interfaces would reveal something similar to: Ingress, first interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/0 Up 9999999999 (9999) 1 (0) -------------------- Egress, second interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/1 Up 0 (0) 9999999999 (0) -------------------- Dropped packets will not show up in DDoS monitoring/protection counters as issue is not caused by anti-DDoS protection mechanisms. This issue affects: Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S7 on NFX250, QFX5K Series, EX4600; 17.4 versions prior to 17.4R2-S11, 17.4R3-S3 on NFX250, QFX5K Series, EX4600; 18.1 versions prior to 18.1R3-S9 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4600; 18.2 versions prior to 18.2R3-S3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600; 18.3 versions prior to 18.3R3-S1 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.1 versions prior to 19.1R1-S5, 19.1R2-S1, 19.1R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.2 versions prior to 19.2R1-S5, 19.2R2 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.3 versions prior to 19.3R2-S3, 19.3R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.4 versions prior to 19.4R1-S2, 19.4R2 on NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series. This issue does not affect Junos OS releases prior to 17.2R2.

When the "Intrusion Detection Service" (IDS) feature is configured on Juniper Networks MX series with a dynamic firewall filter using IPv6 source or destination prefix, it may incorrectly match the prefix as /32, causing the filter to block unexpected traffic. This issue affects only IPv6 prefixes when used as source and destination. This issue affects MX Series devices using MS-MPC, MS-MIC or MS-SPC3 service cards with IDS service configured. This issue affects: Juniper Networks Junos OS 17.3 versions prior to 17.3R3-S10 on MX Series; 17.4 versions prior to 17.4R3-S3 on MX Series; 18.1 versions prior to 18.1R3-S11 on MX Series; 18.2 versions prior to 18.2R3-S6 on MX Series; 18.3 versions prior to 18.3R3-S4 on MX Series; 18.4 versions prior to 18.4R3-S6 on MX Series; 19.1 versions prior to 19.1R2-S2, 19.1R3-S3 on MX Series; 19.2 versions prior to 19.2R3-S1 on MX Series; 19.3 versions prior to 19.3R2-S5, 19.3R3-S1 on MX Series; 19.4 versions prior to 19.4R3 on MX Series; 20.1 versions prior to 20.1R2 on MX Series; 20.2 versions prior to 20.2R2 on MX Series;

Coturn is free open source implementation of TURN and STUN Server. Coturn before version 4.5.2 by default does not allow peers to connect and relay packets to loopback addresses in the range of `127.x.x.x`. However, it was observed that when sending a `CONNECT` request with the `XOR-PEER-ADDRESS` value of `0.0.0.0`, a successful response was received and subsequently, `CONNECTIONBIND` also received a successful response. Coturn then is able to relay packets to the loopback interface. Additionally, when coturn is listening on IPv6, which is default, the loopback interface can also be reached by making use of either `[::1]` or `[::]` as the peer address. By using the address `0.0.0.0` as the peer address, a malicious user will be able to relay packets to the loopback interface, unless `--denied-peer-ip=0.0.0.0` (or similar) has been specified. Since the default configuration implies that loopback peers are not allowed, coturn administrators may choose to not set the `denied-peer-ip` setting. The issue patched in version 4.5.2. As a workaround the addresses in the address block `0.0.0.0/8`, `[::1]` and `[::]` should be denied by default unless `--allow-loopback-peers` has been specified.

An issue was discovered in Treck IPv6 before 6.0.1.68. Improper Input Validation in the DHCPv6 client component allows an unauthenticated remote attacker to cause an Out of Bounds Read, and possibly a Denial of Service via adjacent network access.

An issue was discovered in Treck IPv6 before 6.0.1.68. Improper Input Validation in the IPv6 component allows an unauthenticated remote attacker to cause an Out of Bounds Write, and possibly a Denial of Service via network access.

An issue was discovered in Treck IPv6 before 6.0.1.68. Improper input validation in the IPv6 component when handling a packet sent by an unauthenticated remote attacker could result in an out-of-bounds read of up to three bytes via network access.

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 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 _fnet_ip6_reassembly in fnet_ip6.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 _fnet_ip6_ext_header_handler_options in fnet_ip6.c, leading to Denial-of-Service.

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 pico_ipv6_process_destopt() in pico_ipv6.c.

An issue was discovered in picoTCP 1.7.0. The routine for processing the next header field (and deducing whether the IPv6 extension headers are valid) doesn't check whether the header extension length field would overflow. Therefore, if it wraps around to zero, iterating through the extension headers will not increment the current data pointer. This leads to an infinite loop and Denial-of-Service in pico_ipv6_check_headers_sequence() in pico_ipv6.c.

An issue was discovered in picoTCP 1.7.0. The code for parsing the hop-by-hop IPv6 extension headers does not validate the bounds of the extension header length value, which may result in Integer Wraparound. Therefore, a crafted extension header length value may cause Denial-of-Service because it affects the loop in which the extension headers are parsed in pico_ipv6_process_hopbyhop() in pico_ipv6.c.