TristanInSec [Mon, 18 May 2026 18:39:44 +0000 (14:39 -0400)]
dissect: use practical 16 MiB limit instead of SSIZE_MAX
As suggested by @yuwata, SSIZE_MAX is still too large and would cause
malloc() to fail anyway. Use a 16 MiB limit which is generous compared
to the typical 4 MiB maximum in cryptsetup (LUKS2_HDR_OFFSET_MAX).
TristanInSec [Mon, 18 May 2026 17:30:02 +0000 (13:30 -0400)]
dissect: guard against ssize_t overflow in LUKS2 header parser
The json_len variable is ssize_t, but the subtraction
be64toh(header.hdr_len) - LUKS2_FIXED_HDR_SIZE can yield a value
exceeding SSIZE_MAX when hdr_len is a large crafted value. This causes
signed integer overflow and a subsequent oversized malloc() that fails
with -ENOMEM, producing a misleading out-of-memory error.
Add an explicit check against SSIZE_MAX before the cast to ssize_t.
Ivan Kruglov [Mon, 18 May 2026 10:57:43 +0000 (03:57 -0700)]
errno-util: include -ENOENT in ERRNO_IS_XATTR_ABSENT()
The getxattr(2) man page only enumerates xattr-specific errors (ENODATA,
ENOTSUP, ERANGE, E2BIG, ...) in its own ERRORS section, but at the
bottom of that section notes that "the errors documented in stat(2) can
also be returned." stat(2) returns -ENOENT when a component of the path
does not exist, so any xattr lookup against a path can fail with -ENOENT
exactly the same way as -ENODATA — both mean "there is nothing here for
me to read." The previous definition of ERRNO_IS_NEG_XATTR_ABSENT()
reflected only the directly-enumerated errors and missed -ENOENT, so
callers that should semantically swallow "the xattr is absent" instead
bubbled -ENOENT up as a hard error.
The most visible consequence on real fleets has been systemd-journald
spamming dmesg with one line per dispatched log message whenever a
unit's cgroup directory cannot be found at the time
client_context_read_log_filter_patterns() is called — typically inside
containers whose journald observes clients whose unit cgroup is no
longer present in its view (cgroup-namespace boundary, unit teardown
race, transient sub-scope already collapsed back to its unit cgroup,
etc.). The same bug pattern lurks at every other cgroup-xattr callsite:
systemd-oomd reading user.oomd_avoid / user.oomd_omit / user.oomd_ooms
on cgroups it is concurrently killing; killall reading
user.survive_final_kill_signal during shutdown; cg_is_delegated() /
cg_has_coredump_receive() / cgroup_get_managed_oom_kill_last(); etc. For
these, "path is gone" is by construction the same answer as "xattr is
not set" — there is no way for the user to have attached an xattr to a
path that does not exist.
A quick survey of non-cgroup callers (src/portable/portable.c,
src/home/{homework-luks,user-record-util}.c,
src/random-seed/random-seed-tool.c, src/basic/os-util.c) confirms they
all operate on fds or on paths whose absence is already the desired
silent-skip outcome, so widening the macro to also fold in -ENOENT does
not change observable behavior at any other site.
Extend test-xattr-util's getxattr_at_malloc test with an explicit
non-existent-path lookup that asserts ERRNO_IS_NEG_XATTR_ABSENT() now
matches, alongside the pre-existing non-existent-xattr (-ENODATA) check.
Luca Boccassi [Mon, 18 May 2026 11:05:10 +0000 (12:05 +0100)]
dhcp-client: reject messages larger than the maximum UDP payload
dhcp_message_verify_header() only enforced a lower bound on the input
length, so dhcp_message_parse() happily accepted arbitrarily large
buffers. Such inputs could never have been received via UDP and would
later fail in dhcp_message_build() with -E2BIG once the parsed options'
combined size exceeds UDP_PAYLOAD_MAX_SIZE, which the fuzzer surfaced as
an assertion failure.
Reject inputs above UDP_PAYLOAD_MAX_SIZE up front, so the parse stage
mirrors what the wire format can actually carry.
ishwarbb [Mon, 23 Mar 2026 13:02:40 +0000 (13:02 +0000)]
resolved: add configurable DNS cache size
Add CacheSize= option to [Resolve] section of resolved.conf to allow
configuring the maximum number of entries in the per-scope DNS cache.
The default remains 4096 entries. Setting this to 0 disables caching
(similar to Cache=no).
CacheSize= is only read when Cache=yes or Cache=no-negative. When
Cache=no, caching is fully disabled regardless of CacheSize=.
Changes:
- Add cache_size field to Manager struct
- Parse CacheSize= from resolved.conf via gperf
- Thread cache_size through dns_cache_put() and helper functions
- Replace hard-coded CACHE_MAX with the configurable cache_size
- When cache_size is 0 or Cache=no, flush cache and skip caching
- Add man page documentation for the new option
- Add unit tests for cache size enforcement
coredump: use a fixed string instead a scope-delimited compound literal
The compound literal (const char[]){'.','.','.'} has block scope
(C99 6.5.2.5p6). Once we leave the if and loop back, copy[1].iov_base
formally points into a destroyed object. Works on GCC/Clang in practice,
but is UB.
core/dbus-execute: propagate oom in property_get_cpu_affinity
The function already returns errors, so I'm not sure why we ignored
the error in the second call, potentially leaving variables unitialized.
It seems easiest to propagate the error.
Yu Watanabe [Sun, 17 May 2026 23:40:44 +0000 (08:40 +0900)]
network/address: drop duplicated address earlier
network_adjust_dhcp_server() searches network->addresses_by_section,
hence without this change, an address entry picked by
network_adjust_dhcp_server() may be detached and freed by the cleanup
function.
Luca Boccassi [Sun, 17 May 2026 17:22:20 +0000 (18:22 +0100)]
dhcp-client: clear overloaded sname/file fields after parsing
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.
Yu Watanabe [Wed, 11 Mar 2026 22:00:06 +0000 (07:00 +0900)]
tree-wide: use device_get_sysattr_safe_string()
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.
Yu Watanabe [Wed, 11 Mar 2026 20:44:51 +0000 (05:44 +0900)]
sd-device: use device_get_sysattr_safe_string()
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.
Jörg Behrmann [Tue, 24 Feb 2026 17:08:30 +0000 (18:08 +0100)]
emacs: add settings for Python modes
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.