| Commit message (Collapse) | Author | Files | Lines |
|
Some paragraphs were narrow for no good reason. Let's make things
a bit more uniform.
|
|
"left from <something>" is not correct. "left <something>" would be the
usual form, but "left master interface" is not clear at all. So reword
those messages totally.
Follow-up for 3881fd406b13746336c6c654fd2f68261161fd8a.
|
|
|
|
The original issue oss-fuzz#10734 (https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10734)
is that just the file size is too large, and not a issue in functions
tested by the fuzzer. It is not necessary to include the testcase.
Follow-up for c4f883b78e5ffd326a82eaf18e01a9e4e243db58.
Fixes #23390.
|
|
|
|
Passing potentially arbitrary data into a shellscript is potentially
very broken if you do not correctly quote it for use. This quoting must
be done as part of the interpretation of the data itself, e.g. python's
shlex.quote; simply formatting it into a string with double quotes is
NOT sufficient.
An alternative is to communicate the data reliably via argv to the shell
process, and allow the shell to internally handle it via `"$1"`, which
is quote-safe and will expand the data from argv as a single tokenized
word.
|
|
|
|
|
|
|
|
|
|
As DnssdService object passed to dnssd_render_instance_name() may
not owned by Manager.
Fixes #23381.
|
|
Add accel orientation for the Cube iWork 10 I15-TG
|
|
This fixes a minor bug introduced by 10af8bb24b39a815079f6bf31b449c6e5aaa2adf.
Before the commit, the interface group was set only when Group= is explicitly
specified, otherwise the interface group was kept. However, after the commit,
we need to specify Group= with an empty string to keep the current interface
group.
|
|
|
|
|
|
|
|
|
|
|
|
Fixes: #23374
Fixes: 367165a4069ac0c04882a05a8a80f6afb1e42760
|
|
Fixes a bug introduced by 71aee23dba7faeef68e7232f444626267a6c90d7.
Fixes CID#1488763.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to work
let's not make up new errors in these checks that validate if connect()
work at all. After all, we don't really know if the ENXIO we saw earlier
actually is really caused by the inode being an AF_UNIX socket, we just
have the suspicion...
|
|
108ch limit
This way we can implement nice fallbacks later on.
While we are at it, provide a test for this (one that is a bit over the
top, but then again, we can never have enough tests).
|
|
It is mostly deprecated on Fedora.
|
|
|
|
The issue #12953 is caused by the following:
On switching root,
- deserialized_found == DEVICE_FOUND_UDEV | DEVICE_FOUND_MOUNT,
- deserialized_state == DEVICE_PLUGGED,
- enumerated_found == DEVICE_FOUND_MOUNT,
On switching root, most devices are not found by the enumeration process.
Hence, the device state is set to plugged by device_coldplug(), and then
changed to the dead state in device_catchup(). So the corresponding
mount point is unmounted. Later when the device is processed by udevd, it
will be changed to plugged state again.
The issue #23208 is caused by the fact that generated udev database in
initramfs and the main system are often different.
So, the two issues have the same root; we should not honor
DEVICE_FOUND_UDEV bit in the deserialized_found on switching root.
This partially reverts c6e892bc0eebe1d42c282bd2d8bae149fbeba85f.
Fixes #12953 and #23208.
Replaces #23215.
Co-authored-by: Martin Wilck <mwilck@suse.com>
|
|
|
|
There exist /sys/class/gpio and /sys/bus/gpio, and both have gpiochip%N
device. However, these point to different devpaths.
|
|
Previously, in sd_device_new_from_subsystem_sysname(), '/' in sysname
was replaced '!' for several limited subsystems. This was based on a wrong
assumption that no sysname in e.g. driver subsystem does not contain '!'.
And the assumption is actually wrong, and trigger issue #23327.
In device_set_sysname_and_sysnum() we unconditionally replace '!' in the
filename. Hence, the translation in sd_device_new_from_subsystem_sysname()
must be also done unconditionally.
Fixes #23327.
|
|
|
|
|
|
|
|
|
|
|
|
C.f. ce913e0ec4c97651c7c1509b72fb81ee61d80c6a.
|
|
|
|
|
|
This way we can still call fuzzers on old samples, but oss-fuzz will not waste
its and our time finding overly large inputs.
|
|
|
|
Without the size limits, oss-fuzz creates huge samples that time out. Usually
this is because some of our code has bad algorithmic complexity. For data like
configuration samples we don't need to care about this: non-rogue configs are
rarely more than a few items, and a bit of a slowdown with a few hundred items
is acceptable. This wouldn't be OK for processing of untrusted data though.
We need to set the limit in two ways: through .options and in the code. The
first because it nicely allows libFuzzer to avoid wasting time, and the second
because fuzzers like hongfuzz and afl don't support .options.
While at it, let's fix an off-by-one (65535 is the largest offset for a
power-of-two size, but we're checking the size here).
Co-authored-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
|
|
It was added originally back in 2bd37c5be2f09950f26351506a00929c8719ea15,
but there doesn't seem to by any particular reason for it.
|
|
Fixes a bug introduced by d8b50e5df7e01983279e70c6d970fb60d053df97.
Fixes https://github.com/systemd/systemd/pull/22662#issuecomment-1124163773.
Fixes RHBZ#2083374 (https://bugzilla.redhat.com/show_bug.cgi?id=2083374).
|
|
There are memory leaks there https://github.com/bus1/dbus-broker/issues/289
and it crashes from time to time
https://github.com/matusmarhefka/dfuzzer/issues/20#issuecomment-1114097840
so let's just skip it by analogy with dbus-daemon to avoid
reports that have nothing to do with systemd itself.
It's kind of a part of https://github.com/systemd/systemd/pull/22547
|
|
The methods published by the example have a reply in the signature, but
the code was not sending any, so the client gets stuck waiting for a
response that doesn't arrive. Echo back the input string.
Update the object path to follow what would be the canonical format.
Request a service name on the bus, so that the code can be dropped in a
service and it can be dbus-activatable. It also makes it easier to see
on busctl list.
|