It was reported that accept4() will return -1 with errrno is EINVAL on
arm platform, so check EINVAL for accept4() and retry accept().
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69026
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If SOCK_CLOEXEC is defined (usually because accept4 is implemented),
check for EPROTOTYPE (the POSIX errno for invalid socket types) in
addition to EINVAL as errno indicating whether socket and socketpair
do not support SOCK_CLOEXEC (and other SOCK_* flags).
[adapted by Chengwei Yang to give _dbus_connect_exec() the same treatment]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69073
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
As the same as _dbus_open_socket() and _dbus_full_duplex_pipe(),
socketpair() may fail with EINVAL if call with SOCK_CLOEXEC.
Check for the failure and retry without SOCK_CLOEXEC, in addition, only
call _dbus_fd_set_close_on_exec() if the socketpair failure happened.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69073
[trivial coding style fixes -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The function dbus_connection_set_route_peer_messages() take a bool
argument, however, in the implementation, it always hard-code to TRUE
rather than take its bool argument.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69165
[amended commit message -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Fix a file descriptor not being closed when an error codepath is taken.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69182
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[more specific commit message -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If waitpid() failed with EINTR, we'd go back for another go, but
because ret is nonzero, we'd skip the waitpid() and just keep looping.
Also avoid an unnecessary "goto" in favour of a proper loop, to make it
more clearly correct.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68945
Reviewed-by: Colin Walters <walters@verbum.org>
This test was failing on s390; though it could fail
on other platforms too. Basically we need to be sure
we're passing at least word-aligned buffers to the
demarshalling code. malloc() will do that for us.
https://bugs.freedesktop.org/show_bug.cgi?id=67279
If a byte in DBusString *unescaped isn't a ascii byte, which will be
cast to char (signed char on most of platform), so that's the issue
unsigned char cast to signed char. e.g. "\303\266" is a valid unicode
character, if everything goes right, it will be escaped to "%c3%b6".
However, in fact, it escaped to "%<garbage-byte>3%<garbage-byte>6".
_dbus_string_append_byte_as_hex() take an int parameter, so negative
byte is valid, but cause get a negative index in array. So garbage value
will get. e.g. '\303' --> hexdigits[((signed byte)(-61)) >> 4] is
hexdigits[-4].
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=53499
Sgne-off-by: Chengwei Yang <chengwei.yang@intel.com>
[fixed whitespace -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If the str will be freed hasn't been initialized by _dbus_string_init
correctly, _dbus_string_free may crash due to trying to free an
undefined memory.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65959
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Using a va_list more than once is non-portable: it happens to work
under the ABI of (for instance) x86 Linux, but not x86-64 Linux.
This led to _dbus_printf_string_upper_bound() crashing if it should
have returned exactly 1024 bytes. Many system services can be induced
to process a caller-controlled string in ways that
end up using _dbus_printf_string_upper_bound(), so this is a denial of
service.
Reviewed-by: Thiago Macieira <thiago@kde.org>
dbus-daemon will crash due to invalid service file which key/value
starts before section. In that situation, new_line() will try to access
invalid address.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60853
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When dbus-daemon receives a request to activate a systemd service before
systemd has connected to it, it enqueues a fake request to "activate"
systemd itself (as a way to get a BusPendingActivationEntry to track the
process of waiting for systemd). When systemd later joins the bus,
dbus-daemon sends the actual activation message; any future activation
messages are sent directly to systemd.
In the "pending" code path, the activation messages are currently
dispatched as though they had been sent by the same process that sent
the original activation request, which is wrong: the bus security
policy probably doesn't allow that process to talk to systemd directly.
They should be dispatched as though they had been sent by the
dbus-daemon itself (connection == NULL), the same as in the non-pending
code path.
In the worst case, if the attempt to activate systemd timed out, the
dbus-daemon would crash with a (fatal) warning, because in this special
case, activation_message is a signal with no serial number, whereas the
code to send an error reply is expecting a method call with a serial
number.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50199
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Tested-by: Ma Yu <yu.ma@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Unicode Corrigendum #9 clarifies that the non-characters U+nFFFE
(for n in the range 0 to 0x10), U+nFFFF (for n in the same range),
and U+FDD0..U+FDEF are valid for interchange, and their presence
does not make a string ill-formed.
GLib 2.36 made the corresponding change in its definition of UTF-8
as used by g_utf8_validate() and similar functions.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63072
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Also warn if we inadvertently use a function introduced since then.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Reviewed-by: Colin Walters <walters@verbum.org>
If DBUS_DISABLE_ASSERTS was turned on, and a buggy program called
dbus_connection_get_data() with a slot number less than zero (eg,
before even allocating the data slot), random memory would be
accessed and a random value returned. Anything less than zero
is not a valid slot number and should be rejected by libdbus.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63127
Signed-off-by: Dan Williams <dcbw@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
