After the recent reworking of this code it was possible for `g_close()`
to be called on `fd == -1`, which is invalid. It would have reported an
error, were errors not ignored. So it was harmless, but still best to
fix.
Simplify the error handling by combining both error labels and checking
the state of `fd` dynamically.
Coverity CID: #1450834
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit c4b4fecaef)
The `G_FILE_CREATE_REPLACE_DESTINATION` flag is equivalent to unlinking
the destination file and re-creating it from scratch. That did
previously work, but in the process the code would call `open(O_CREAT)`
on the file. If the file was a dangling symlink, this would create the
destination file (empty). That’s not an intended side-effect, and has
security implications if the symlink is controlled by a lower-privileged
process.
Fix that by not opening the destination file if it’s a symlink, and
adjusting the rest of the code to cope with
- the fact that `fd == -1` is not an error iff `is_symlink` is true,
- and that `original_stat` will contain the `lstat()` results for the
symlink now, rather than the `stat()` results for its target (again,
iff `is_symlink` is true).
This means that the target of the dangling symlink is no longer created,
which was the bug. The symlink itself continues to be replaced (as
before) with the new file — this is the intended behaviour of
`g_file_replace()`.
The behaviour for non-symlink cases, or cases where the symlink was not
dangling, should be unchanged.
Includes a unit test.
Resolves CVE-2021-28153 (glib#2325). Backported to GLib 2.58 by
Simon McVittie.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry-picked from commit 317b3b5870)
[Backport to 2.58.x: replace g_local_file_fstat with fstat]
[Backport to 2.58.x: replace g_local_file_lstat with lstat]
[Backport to 2.58.x: replace _g_stat_mode with direct access to st_mode]
[Backport to 2.58.x: don't call g_test_summary()]
Signed-off-by: Simon McVittie <smcv@collabora.com>
This clarifies the code a little. It introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit ce0eb088a6)
Since a following commit is going to add a new test which references
Gitlab, so it’s best to move the URI bases inside the test cases.
Backported to GLib 2.58 by Simon McVittie.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry-picked from commit 32d3d02a50)
[GLib 2.58.x did not allow g_test_bug() without g_test_bug_base(),
so use an empty string as the base]
Signed-off-by: Simon McVittie <smcv@collabora.com>
This allows it to handle strings up to length `G_MAXSIZE` — previously
it would overflow with such strings.
Update the several copies of it identically.
Adapted for GLib 2.58 by Simon McVittie.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
[Backport to 2.58 branch: g_wcsdup() existed in different places]
Signed-off-by: Simon McVittie <smcv@collabora.com>
The members of `URL_COMPONENTS` (`winhttp_file->url`) are `DWORD`s, i.e.
32-bit unsigned integers. Adding to and multiplying them may cause them
to overflow the unsigned integer bounds, even if the result is passed to
`g_memdup2()` which accepts a `gsize`.
Cast the `URL_COMPONENTS` members to `gsize` first to ensure that the
arithmetic is done in terms of `gsize`s rather than unsigned integers.
Spotted by Sebastian Dröge.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
(cherry picked from commit 0cbad67321)
This code no longer existed on the glib-2-66 branch, but it's present
in glib-2-58. It's easier to verify that all potentially problematic
g_memdup() uses have been replaced if we replace these too.
Helps: #2319
Signed-off-by: Simon McVittie <smcv@collabora.com>
GByteArray uses guint for storing the length of the byte array, but it
also has a constructor (g_byte_array_new_take) that takes length as a
gsize. gsize may be larger than guint (64 bits for gsize vs 32 bits
for guint). It is possible to call the function with a value greater
than G_MAXUINT, which will result in silent length truncation. This
may happen as a result of unreffing GBytes into GByteArray, so rather
be loud about it.
(Test case tweaked by Philip Withnall.)
(Backport 2.66: Add #include gstrfuncsprivate.h in the test case for
`g_memdup2()`.)
(cherry picked from commit 0f384c88a2)
Fixes: CVE-2021-27218
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.
In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
(cherry picked from commit be8834340a)
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.
In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
(cherry picked from commit 6110caea45)
Backport of part of commit 0736b7c1e7
to the simpler structure of the GHashTable code in glib-2-58.
Helps: #2319
Signed-off-by: Simon McVittie <smcv@collabora.com>
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()` or an existing `gsize`
variable), so that they use `g_memdup2()` instead.
In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it
In particular, this fixes an overflow within `g_bytes_new()`, identified
as GHSL-2021-045 (aka CVE-2021-27219) by GHSL team member Kevin Backhouse.
Adapted for GLib 2.58 by Simon McVittie.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: CVE-2021-27219
Fixes: GHSL-2021-045
Helps: #2319
(cherry picked from commit 0736b7c1e7)
[Backport to 2.58: Omit changes to ghash.c, will be a separate commit]
[Backport to 2.58: Omit changes to giochannel.c, not needed in this branch]
[Backport to 2.58: Omit changes to uri test, not needed in this branch]
Signed-off-by: Simon McVittie <smcv@collabora.com>
This will replace the existing `g_memdup()` function for use within
GLib. It has an unavoidable security flaw of taking its `byte_size`
argument as a `guint` rather than as a `gsize`. Most callers will
expect it to be a `gsize`, and may pass in large values which could
silently be truncated, resulting in an undersize allocation compared
to what the caller expects.
This could lead to a classic buffer overflow vulnerability for many
callers of `g_memdup()`.
`g_memdup2()`, in comparison, takes its `byte_size` as a `gsize`.
Spotted by Kevin Backhouse of GHSL.
In GLib 2.68, `g_memdup2()` will be a new public API. In this version
for backport to older stable releases, it’s a new `static inline` API
in a private header, so that use of `g_memdup()` within GLib can be
fixed without adding a new API in a stable release series.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: CVE-2021-27219
Helps: GHSL-2021-045
Helps: #2319
(cherry picked from commit 5e5f75a77e)
If we can't find the mount point for target or tmp (as currently
happens on Launchpad autobuilders, and perhaps relatedly, on a
development system that uses btrfs), that's probably not great but is
not really the point of this test.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 13282768c7)
In a minimal autobuilder environment, this test could conceivably be
the first thing to refer to ~/.local.
Modified by Iain Lane <laney@debian.org>: Don't try to create ~/.local
from tests, but skip if it doesn't exist.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 56a5cd1337)
Commit ed88b23f added libmount-based implementation to filter out mounts
with repeated device path. Unfortunately, this introduced a new bug, which
may cause segfaults from in certain configurations.
The problem is that `mnt_table_uniq_fs ()` is called from the loop which
already operates with the `fs` structs from that table. It may happen that
the current `fs` is removed from the table, which may consequently lead to
segfaults.
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1645
glib!552 (commit 9eed22b3) fixed this for the tests that failed on i686,
but this additional test failed on Debian's s390x port
(IBM z/Architecture, 64-bit big-endian).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Note that it's not reported with gcc. It's only reported with g++.
C++ code to reproduce this warning:
#include <glib-object.h>
G_BEGIN_DECLS
#define GARROW_TYPE_FILE (garrow_file_get_type())
G_DECLARE_INTERFACE(GArrowFile,
garrow_file,
GARROW,
FILE,
GObject)
struct _GArrowFileInterface {
GTypeInterface g_iface;
};
G_DEFINE_INTERFACE(GArrowFile,
garrow_file,
G_TYPE_OBJECT)
static void
garrow_file_default_init(GArrowFileInterface *iface)
{
}
G_END_DECLS
Build command line:
% g++ -Wall -shared -o liba.so a.cpp $(pkg-config --cflags --libs gobject-2.0)
Message:
In file included from /tmp/local.glib/include/glib-2.0/gobject/gobject.h:24,
from /tmp/local.glib/include/glib-2.0/gobject/gbinding.h:29,
from /tmp/local.glib/include/glib-2.0/glib-object.h:23,
from a.cpp:1:
a.cpp: In function 'GType garrow_file_get_type()':
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:219:50: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
#define G_TYPE_MAKE_FUNDAMENTAL(x) ((GType) ((x) << G_TYPE_FUNDAMENTAL_SHIFT))
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:2026:11: note: in definition of macro '_G_DEFINE_INTERFACE_EXTENDED_BEGIN'
if (TYPE_PREREQ) \
^~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:1758:47: note: in expansion of macro 'G_DEFINE_INTERFACE_WITH_CODE'
#define G_DEFINE_INTERFACE(TN, t_n, T_P) G_DEFINE_INTERFACE_WITH_CODE(TN, t_n, T_P, ;)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.cpp:16:1: note: in expansion of macro 'G_DEFINE_INTERFACE'
G_DEFINE_INTERFACE(GArrowFile,
^~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:178:25: note: in expansion of macro 'G_TYPE_MAKE_FUNDAMENTAL'
#define G_TYPE_OBJECT G_TYPE_MAKE_FUNDAMENTAL (20)
^~~~~~~~~~~~~~~~~~~~~~~
a.cpp:18:20: note: in expansion of macro 'G_TYPE_OBJECT'
G_TYPE_OBJECT)
^~~~~~~~~~~~~
This reverts commit a2375b8929.
It adds new API, and hence should not have been merged to the stable
branch. This commit will remain in place on master (which will become
GLib 2.60).
This reverts commit 13c088df13.
It depends on new API added in commit a2375b8929, which should not have
been merged to the stable branch. This commit will remain in place on
master (which will become GLib 2.60).
This reverts commit 6e75d3cf17.
It depends on new API added in commit a2375b8929, which should not have
been merged to the stable branch. This commit will remain in place on
master (which will become GLib 2.60).
On non-systemd Gentoo systems the chosen timezone is expressed in
/etc/timezone and /etc/localtime may be a copy of the timezone
file instead of symlink. Add this path to the fallback test to
not regress dates into UTC.
This means the output (including lists of filenames) does not depend on
the order of the input files, which may matter if this tool is invoked
with a glob or some other mechanism that doesn't guarantee an order.
Previously, method and signal arguments were sorted by name, which
(assuming you don't happen to give your arguments
lexicographically-ordered names) means the generated signatures were
incorrect when there is more than 1 argument.
While sorting the methods and signals themselves (and properties, and
annotations on all these) is fine, it's easiest to not sort anything.
