CVE-2020-17470

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...

CVE-2020-17470

CVE-2020-17470 affects FNET (up to 4.6.4) where DNS client interface initialization leaves DNS transaction IDs non-random (always 1 in _fnet_dns_poll in fnet_dns.c), making DNS cache poisoning more feasible. The CVE is documented with a MEDIUM base score (~4.0–5.3 range in the CVSS vectors) and i...

CVE-2020-17470

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...

CVE-2020-17469

Concrete details available: CVE-2020-17469 affects FNET up to version 4.6.4 in the IPv6 fragment reassembly path. The bug is an uninitialized pointer dereference in _fnet_ip6_reassembly (fnet_ip6.c) when handling fragments with holes in a non-empty list, enabling Denial-of-Service. Affects FNET's...

CVE-2020-17469

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...

CVE-2020-17469

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...

CVE-2020-17468

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...

CVE-2020-17468

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...

CVE-2020-17468

CVE-2020-17468 – FNET : A flaw in FNET up to v4.6.4 in the IPv6 hop-by-hop extension header processing does not validate the extension header length, enabling an out-of-bounds read that can cause Denial-of-Service. Connected sources corroborate the issue as part of AMNESIA:33, affecting FNET’s fn...

CVE-2020-17467

The CVE-2020-17467 issue affects the FNET stack up to version 4.6.4, where hostname processing for LLMNR requests does not terminate with a null character. This can cause the code path in fnet_llmnr_poll to deduce an incorrect hostname length, enabling information disclosure in responses to malic...

CVE-2020-17467

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 fnetllmnrpo...

CVE-2020-17467

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 fnetllmnrpo...

CVE-2020-17467: Out-of-bounds Read

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 fnetllmnrpo...

PT-2020-15011 · Fnet · Fnet

Name of the Vulnerable Software and Affected Versions: FNET versions through 4.6.4 Description: An issue in the IPv6 fragment reassembly code causes an uninitialized pointer dereference in the fnet ip6 reassembly function in fnet ip6.c, leading to a Denial-of-Service. This occurs when the code...

PT-2020-15010 · Fnet · Fnet

Name of the Vulnerable Software and Affected Versions: FNET versions through 4.6.4 Description: An issue was discovered in the code for processing the hop-by-hop header in the IPv6 extension headers. The code does not check for a valid length of an extension header, which can lead to an...

CVE-2020-17468: Out-of-bounds Read

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...

CVE-2020-17470: Use of Insufficiently Random Values

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...

CVE-2020-17469: Access of Uninitialized Pointer

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...

PT-2020-15009 · Fnet · Fnet

Name of the Vulnerable Software and Affected Versions: FNET versions through 4.6.4 Description: An issue was discovered in the code for processing the hostname from an LLMNR request, which doesn't check for '0' termination. This may lead to Information Disclosure in fnet llmnr poll in fnet llmnr....

CVE-2020-24383: Out-of-bounds Read

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...