Split out of https://github.com/systemd/systemd/pull/42983 ## Problem `dns_packet_append_name()` fails with `-EEXIST` once a name that was first appended at an offset beyond RFC 1035's 14-bit compression-pointer range (0x4000) occurs again in the same packet: the fall-through that re-emits the labels trips `hashmap_ensure_put()` on the existing map entry, and the whole packet build fails — reported by the caller as, for example, "Failed to build reply packet: File exists". The map is meant to hold only offsets a pointer can actually reference. Names past that range were being inserted anyway, so they were dead weight that could never be pointed at, and re-encountering one turned into an error. ## Fix Keep names at offsets ≥ 0x4000 out of the compression map entirely. "Mapped implies referenceable" becomes an invariant of the map rather than something callers have to reason about, and the `-EEXIST` collision cannot arise. A re-occurrence of such a name is emitted as labels, still compressed from the first suffix that *is* mapped in range — which is the only encoding RFC 1035 section 4.1.4 permits in that case, since a pointer must address ≤ 0x3FFF. ## Impact Any packet large enough to push a name past 16KiB hits this — it is not mDNS-specific, though that is where it was found: a DNS-SD announcement covering a few hundred published services crosses the threshold easily, and every record after it fails to encode. ## Test `test-dns-packet-append` gains coverage for the boundary: a name first written past the pointer range and then repeated, the same for a full resource record, the rollback path when an append fails mid-name, and the map invariant itself (asserted over the whole map, so a future change that inserts an unreferenceable offset is caught rather than silently reintroducing the bug). ## Testing status Builds clean with `-Dwerror=true`; `meson test --suite resolve` passes (19 ok, 1 skipped) at both commits.
System and Service Manager
Details
Most documentation is available on systemd's website.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release
