CVE-2025-1675 is a high severity out-of-bounds read in the Zephyr RTOS DNS code, scored 8.2. The function dns_copy_qname trusts a length taken from the packet. Zephyr 4.0 and earlier are affected, and the advisory points to backported patches rather than a released fix.
What's affected
The function dns_copy_qname in dns_pack.c performs a memcpy using a label length read from a received packet. It checks that the destination buffer is large enough but not that the source buffer holds that many bytes.
- Product: Zephyr RTOS (zephyrproject-rtos/zephyr)
- Affected: versions up to and including 4.0, per the GitHub advisory
- Fixed: the advisory lists no released patched version. It lists patches for main (pull request 82072), for v4.0.0 (82289) and for v3.7.0 (82288). Check the project's release notes for a tagged release that includes them.
- Severity: High, CVSS 8.2 in the record (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H)
- Known exploited (CISA KEV): no, the record's kev flag is false
The advisory says the fix is to correct the size check so that it accounts for the label length against the smaller of the remaining buffer size and the message size.
How to check if you're exposed
Firmware teams should check three things.
- Which Zephyr version your product builds against. In a west workspace, run
west list zephyr, or rungit -C zephyr describe --tagsin the Zephyr tree. - Whether the DNS resolver is compiled in. Look for the DNS resolver option in your build configuration, for example
grep -i DNS_RESOLVER build/zephyr/.config. - Whether the device processes DNS responses from networks you do not control. A device that resolves names over the open internet or an untrusted LAN is more exposed than one that never does.
Your software bill of materials should list the Zephyr version for each firmware image. If it does not, that is the first thing to fix, because this kind of issue is only findable when you know what is inside each release.
What to do now
- Identify every product and release built on Zephyr 4.0 or earlier.
- Apply the patch from the advisory for your branch, or move to a Zephyr release that contains it once the project confirms one.
- Rebuild the firmware and plan an update path for devices in the field. Devices that cannot be updated need network controls instead.
- Limit which DNS servers the device will use, so responses come from resolvers you run or trust.
- Add watchdog or crash reporting where you can, since the advisory notes that devices with memory protection may crash.
- Keep a record of which firmware versions carry the fix.
Why it matters
The weakness is an out-of-bounds read (CWE-125). The code believes a length that came off the wire. Reading past the end of the packet buffer is the result.
The advisory describes two outcomes. On embedded devices with memory protection, the out-of-bounds read can cause a crash and a denial of service. On devices without memory protection, it can lead to incorrect and unexpected behaviour. The record scores availability impact as high and confidentiality impact as low.
DNS parsing is a classic place for this bug because the data is attacker controlled and the format uses lengths inside lengths. The defence is to check every length against what is actually left in the buffer before copying.
The record maps this to CWE-125 (Out-of-bounds Read). Safeguard offers a free in-browser dependency scan at gold.safeguard.sh/scan for projects that pull this kind of component in through a package manager.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is CVE-2025-1675 exploited in the wild?
The record's CISA KEV flag is false and the advisory does not say it is being exploited.
Is there a patched Zephyr release?
The advisory listed none when fetched, only patches for main, v4.0.0 and v3.7.0. Check the Zephyr release notes for a tagged release that includes them.
Sources
Last reviewed: 19 October 2026.
