When SD_DHCP_OPTION_OVERLOAD indicates that the sname and/or file header
fields are overloaded with extra DHCP options, dhcp_message_parse() merges
those options into message->options but leaves the raw bytes untouched in
the header. As a result, dhcp_message_build() emits the header (including
the overloaded bytes) verbatim, and the next parse re-parses those bytes,
appending duplicate entries to the options map (each tag's iov list grows).
Subsequent builds then differ from the first, breaking the parse/build
roundtrip.
This was caught by fuzz-dhcp-client, which asserts that two consecutive
build calls produce identical output.
Zero out the overloaded fields after parsing them, since their content has
already been merged into the options map. This makes the roundtrip
idempotent and avoids re-emitting stale overloaded data in the rebuilt
header. The JSON build/parse path was already correct (it omits sname/file
from the JSON when the overload bit is set), so only the binary path needed
fixing.
Fixes https://github.com/systemd/systemd/issues/42139
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
The obtained strings are passed to another function, e,g, handled as a
path and opened, printed to the terminal, written to a file, saved to
udev database as udev property, exposed through DBus, passed to logger,
and so on. Hence, these should not contain any malicious characters.
The read value are exposed by sd_device_get_subsystem() and friends.
Hence, it is better to filter invalid characters.
Of course, these should be always safe unless the kernel is buggy.
But, just for safety.
Note, even if uevent file contains invalid characters, then
device_read_uevent_file() should succeed without parsing the contents.
The caller should fail later with a proper error code if a necessary
field is unset. E.g. sd_device_get_ifindex() should still return -ENOENT
even when uevent file contains an invalid characters.
This introduce a helper function that verifies read sysattr value.
Some sysattr value may come from firmware, and kernel may expose unsafe
string. The introduced function should be used when we use the result as
a string.
Both python-mode and python-ts-mode are shipped by Emacs nowadays, with the
latter being the more modern tree-sitter-based one. Even though they are
similar, the newer one doesn't automatically take the older ones settings.
Jörg Behrmann
Yu Watanabe
RiskoZS
Luca Boccassi