Summary

The function dns_validate_msg in subsys/net/lib/dns/resolve.c validates incoming DNS messages. However, due to an incorrect validation, a malicious or malformed DNS packet without a payload can cause an out-of-bounds read, resulting in a crash (denial of service) or an incorrect computation.

Details

The target function (dns_validate_msg) validates and processes received DNS packets.
However, for packets with DNS ID of 0, QD count of 1 and a missing payload, the crc16_ansi and strlen functions in lines 857-858 will read out-of-bound.

Here is the program flow.

• In line 677, *dns_id may be read as 0.
• In line 698, qdcount is read from the head as 1. This check passes
• dns_unpack_response_query is called in line 706.
  • query_offset is set to value 12 in line 327.
  • Remaining_size is computed as 0 in line 329.
  • rc is 0 in line 331. The dns_unpack_response_query exits in line 333 with a negative value.
• As *dns_id has value 0, the dns_validate_msg function does not quit in line 711, despite the returned error. The function progresses as usual.
• As ancount is 0, this loop in line 731 is not executed.
• In line 852, *query_idx is still -1. Hence, this if block is executed.
• In line 856, query_name pointer is calculated to point to the 13th byte. As the packet only has 12 bytes, this pointer now points out-of-bounds.
• In lines 857 and 858, crc16_ansi and strlen is called with the invalid query_name pointer. This leads to an out-of-bounds read of multiple bytes.

Here is a sample packet that can cause this.
{0, 0, 128, 1, 0, 1, 0, 0, 0, 0, 0, 0};

Impact

In devices with memory protection, this out-of-bound reads will lead to a crash, causing denial of service. In safety-critical devices, this can have severe consequences.
In embedded devices without memory protection, this can cause an invalid computation that impacts device behavior.

Fix Recommendation

We recommend adding a DNS payload validation that verifies that the qdcount and ancount
values present in the header are correct.

Patches

main: #82072

v4.0.0: #82289
v3.7.0: #82288

For more information

If you have any questions or comments about this advisory:

• Open an issue in zephyr
• Email us at Zephyr-vulnerabilities

embargo: 2025-02-13