G_STRUCT_OFFSET (struct sockaddr_un, sun_path) == sizeof (struct sockaddr)
should hold, and therefor the compiler should optimize it away, but it's
not required. So be clear and add it.
If g_socket_address_new_from_native (addr, sizeof (sockaddr_un)) gets
called, the size of the path will be UNIX_PATH_MAX even if it is
a null-terminated string.
Ensure that we return UNIX_PATH_MAX - 1 (because we force null
ternmination) as the path length in this case.
When passing a filename of length UNIX_PATH_MAX via sockaddr_un it will
not be null-terminated. This will cause g_unix_socket_address_new() to
fail as it expects a null-terminated string.
Use g_unix_socket_address_new_with_type() instead as it allows passing a
length.
Testcase included.
Allow addresses of type G_UNIX_SOCKET_ADDRESS_PATH to be UNIX_PATH_MAX
characters long.
Previously they could only be UNIX_PATH_MAX - 1 characters long which
lead to an inconsistency with the UNIX APIs.
There is no implementation reason for this but correctness, where I
feared that AI exploit finders might find an exploit for this and wanted
to get ahead.
Testcase adapted for this usecase.
... so we don't create a file with elevated permissions if not
necessary.
This avoids a potential race where a temporary file is created with
higher priviliges than the result, which is technically a data leak.
Fixes: 45a36e52b5
Resources are generally considered trusted data (after all,
they are typically part of the same binary). But we should
still be robust and avoid underflow if we can. When the data
is not compressed, we subtract 1 from the length of the data
to omit a trailing \0, without checking first if the length
of the data was zero. Don't do that to avoid underflow.
Tests included. The tests were produced and validated with
the help of AI.
Related: RHEL-215289
g_markup_collect_attributes is running cleanup for all attributes,
even those that haven't been processed, because a failure happened
earlier. This is harmless if the out arguments are all
NULL-initialized, but could lead to a wild free if somebody
were to pass the address of an uninitialized pointer.
Tests included. The tests were developed and validated with
the help of AI.
Related: RHEL-221493
_g_utf8_normalize_wc() performs a first pass to count the number of output
`gunichar` elements needed after decomposition, then allocates a buffer from
that count. On 32-bit builds, the unchecked additions into `n_wc` can wrap
before allocation. If that happens, the allocated buffer is too small
and overflow happens during the second pass. Prevent this by using
checked arithmetic where it matters.
Tests included which run only on 32-bit builds. The tests were
produced and validated with the help of AI.
Related: RHEL-216132
g_utf8_strup(), g_utf8_strdown() and g_utf8_casefold() compute
str + len when len is non-negative, which could overflow if str
is near the end of the address space. Add g_return_val_if_fail
checks to prevent this.
Related: RHEL-216604
On Windows, setlocale() alone is not sufficient for GLib to detect
locale-specific casing rules — SetThreadLocale() is also needed.
Add SetThreadLocale() calls for Turkish and Lithuanian locales,
matching the pattern used in test_turkish_strupdown.
Also drop the .UTF-8 suffix from locale names, since it is not
available on Windows.
g_utf8_strdup and g_utf8_strdown take a len argument, but they
can be tricked into reading past that limit, e.g. when doing
lookahead for a combining dot, or when the text section before
the limit ends with a greek iota below (U+0345). Prevent this
by passing the limit to the helper functions that are used
in these cases (append_mark and has_more_above).
Tests included. The tests were produced and validated with
the help of AI.
Related: RHEL-216604
g_utf8_normalize is supposed to return NULL for input that
is not valid UTF-8, but it will sometimes return a valid
prefix up to the first invalid characters.
Use g_utf8_get_char_validated to detect this and return
NULL, as expected.
Tests included. The test were produced and validated with
the help of AI.
Related: RHEL-214768
When too many fields are passed to g_log_writer_journald(), stop using
alloca() for the field arrays and instead use malloc().
This can in theory be exploited remotely via g_log_variant(), but glib
does not use this function.
Testcase included.
When we expect that splitting a string should result in N tokens, we
don't need to split into more than N+1 tokens before we know it's an
error.
This is a hardening suggestion from an AI tool.
The max size is not documented anywhere, so we should be more careful
when checking it and not allow non-assertion builds to skip the overflow
check.
This also brings the code in line with gmem.c which also uses g_error()
on overflows.
Tests included.
When a GVariant was created from invalid data - in particular, from data
that is too small - then it cannot return that invalid data.
In that case, it should probably return NULL but because it is
documented as never returning NULL, we cannot do that. So return a new
GBytes with zeroed data instead.
Fixes efe5b70192
The `g_local_file_trash` function previously truncated filenames from
the front
on a plain byte boundary when encountering `ENAMETOOLONG`. This could
produce
invalid UTF-8 filenames, causing garbled names in the trash for UTF-
8 locales.
A new helper `truncate_basename_front` is introduced that:
- Truncates from the front, preserving the trailing part (extension)
of the
original name.
- For UTF-8 filenames, skips continuation bytes to align the cut to
a character
boundary, ensuring the result remains valid UTF-8.
- For non-UTF-8 (single-byte or best-effort), falls back to a plain
byte cut.
The code now uses this helper in both the `".trashinfo"` suffix and
`".XXXXXX"`
template cases, removing the duplicated inline logic. The helper returns
0 if
the base name is too short to truncate safely, in which case the
original
`ENAMETOOLONG` error is preserved.
The refactoring in !5259 changed the installed service file's
configure_file() to use the build output as input instead of the
original .in template. Since @installed_tests_dir@ is already
substituted in the build output, the installed version gets the
build directory path instead of the install prefix.
Use the .in template directly as input for the installed version.
Closes#4011
It warns that configured files must be referred to by reference rather
than by name, and that support for the latter will be dropped with Meson
2.0.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Feature test macros always need to be defined before any headers are
included. This triggers a redefinition warning with GCC 16 and the new
gnu11 C level.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In the backport commit 4235f7b42 a new string was accidentally added
which broke string freeze. Because it’s very unlikely this string will
be shown (it’s an error message only shown if running a custom D-Bus
server and it’s being attacked by a malicious client), just drop the
translation marker on this stable branch.
The string will get translated for the next stable release on `main`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: https://gitlab.gnome.org/Teams/Translation/Coordination/-/work_items/529
The client isn’t trusted at this point, and there was previously nothing
limiting how long a line `GDBusAuth` would read. So an untrusted client
could exhaust the server’s memory by sending anything except `\r\n`.
Fix that by applying a reasonably length limit when reading a line, and
add a unit test.
Spotted by Gitee Codepecker Lab.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3985
g_type_check_is_value_type and g_type_test_flags both read global memory,
so can't be const. They only seem to write for the purpose of a lock, which
they undo at the end, so maybe we can get away with G_GNUC_PURE here.
Bug: https://gitlab.gnome.org/GNOME/glib/-/work_items/3984
Signed-off-by: Sam James <sam@gentoo.org>
g_type_ensure has a large comment saying _get_type shouldn't be
marked with G_GNUC_CONST because it has side-effects on the first
run, but it's OK if you consistently call g_type_ensure first.
Unfortunately, this isn't accurate. GCC trunk (observed at r17-1725-ge259a182e1f100)
now analyses points-to information more effectively and propagates its
findings, so it sees the function modifies some global state, concludes
that can't be possible (because of the const attribute), and deletes
the stores.
pure unfortunately is unsuitable for *_get_type too as it has a side-effect
(writes to global memory).
Mesa had a similar issue which I fixed recently [0]. glib and glibmm likely
want the (not-yet-implemented) 'idempotent' attribute instead [1]. In fact,
this exact problem is what motivated that request! :)
ebassi mentions an alternative to the current setup as well, using
atomics [2].
This problem has gone back many years but the compiler has finally
fully outsmarted us here, so give in.
[0] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42361
[1] https://gcc.gnu.org/PR32911
[2] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4249#note_2583110
Fixes: https://gitlab.gnome.org/GNOME/glib/-/work_items/3984
Signed-off-by: Sam James <sam@gentoo.org>
