ESP-IDF is the Espressif Internet of Things (IOT) Development Framework

Why it is Yellow

• CVSS 7.4 high
• Remotely exploitable without logging in

References

• https://github.com/espressif/esp-idf/commit/75f2ff7e0c2d19e113293ec122b701c83d2f6665
• https://github.com/espressif/esp-idf/commit/7ab85eb4dc7d7695960d940badcd62592c365056
• https://github.com/espressif/esp-idf/commit/882843dbf838b0c02e09d46bb6283bda73496b8c
• https://github.com/espressif/esp-idf/commit/98e6e7a08fca391563651a1e751cc45a3b27d18b
• https://github.com/espressif/esp-idf/commit/af7543d00a4d7b489e010a70b59fd3d8022a40f4
• https://github.com/espressif/esp-idf/commit/defaa2f559470acfee5e2e5ea80a79b73424d483
• https://github.com/espressif/esp-idf/security/advisories/GHSA-ch63-jxm5-vmvf

Original description

ESP-IDF is the Espressif Internet of Things (IOT) Development Framework. From 5.2.3 until 5.3.7, 5.4.5, 5.5.6, and 6.0.3, the lwIP DNS resolver's cached-lookup path in dns_lookup() in dns.c copies every cached address into a caller-provided single ip_addr_t output buffer without a length parameter or bounds check. When CONFIG_LWIP_DNS_MAX_HOST_IP is greater than 1 and a cached hostname has multiple A or AAAA records, a subsequent lookup through dns_gethostbyname() or dns_gethostbyname_addrtype() writes beyond the single-element buffer into adjacent stack memory. A network-positioned attacker who influences DNS responses can cause a reboot through stack-canary corruption or, without stack protection, overwrite stack variables with attacker-controlled address bytes and potentially redirect control flow. This issue is fixed in versions 5.5.6 and 6.0.3 and is scheduled to be fixed in versions 5.3.7 and 5.4.5. No fixed release is available for the end-of-life 5.2 line.