1. 04 Feb, 2021 2 commits
    • Philip Withnall's avatar
      glib: Use g_memdup2() instead of g_memdup() in obvious places · 0736b7c1
      Philip Withnall authored
      
      
      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 by GHSL team member Kevin Backhouse.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <pwithnall@endlessos.org>
      Fixes: GHSL-2021-045
      Helps: #2319
      0736b7c1
    • Philip Withnall's avatar
      gstrfuncs: Add internal g_memdup2() function · 5e5f75a7
      Philip Withnall authored
      
      
      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's avatarPhilip Withnall <pwithnall@endlessos.org>
      Helps: GHSL-2021-045
      Helps: #2319
      5e5f75a7
  2. 01 Feb, 2021 4 commits
    • Simon McVittie's avatar
      9eb4fe3c
    • Thomas Haller's avatar
      spawn: prefer allocating buffers on stack for small sizes to avoid valgrind leaks · 8a3c3b8c
      Thomas Haller authored
      We preallocate buffers that are used after forked. That is because
      malloc()/free() are not async-signal-safe and must not be used between
      fork() and exec().
      
      However, for the child process that exits without fork, valgrind wrongly
      reports these buffers as leaked.
      That can be suppressed with "--child-silent-after-fork=yes", but it is
      cumbersome.
      
      Work around by trying to allocate the buffers on the stack. At
      least in the common cases where the pointers are small enough
      so that we can reasonably do that.
      
      If the buffers happen to be large, we still allocate them on the heap
      and the problem still happens. Maybe we could have also allocated them
      as thread_local, but currently glib doesn't use that.
      
      [smcv: Cosmetic adjustments to address review comments from pwithnall]
      8a3c3b8c
    • Simon McVittie's avatar
      Add test coverage for G_SPAWN_SEARCH_PATH · 136a9d7f
      Simon McVittie authored
      For manual test coverage that would reproduce the bug fixed in !1902
      
      ,
      copy /bin/true (or any other harmless executable) to
      /usr/bin/spawn-test-helper.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      136a9d7f
    • Simon McVittie's avatar
      spawn: Don't set a search path if we don't want to search PATH · 0d50c6bb
      Simon McVittie authored
      do_exec() and g_execute() rely on being passed a NULL search path
      if we intend to avoid searching the PATH, but since the refactoring
      in commit 62ce66d4, this was never done. This resulted in some spawn
      calls searching the PATH when it was not intended.
      
      Spawn calls that go through the posix_spawn fast-path were unaffected.
      
      The deprecated gtester utility, as used in GTK 3, relies on the
      ability to run an executable from the current working directory by
      omitting the G_SPAWN_SEARCH_PATH flag. This *mostly* worked, because
      our fallback PATH ends with ".". However, if an executable of the
      same name existed in /usr/bin or /bin, it would run that instead of the
      intended test: in particular, GTK 3's build-time tests failed if
      ImageMagick happens to be installed, because gtester would accidentally
      run display(1) instead of testsuite/gdk/display.
      
      Fixes: 62ce66d4 "gspawn: Don’t use getenv() in async-signal-safe context"
      Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977961
      0d50c6bb
  3. 30 Dec, 2020 1 commit
  4. 21 Dec, 2020 2 commits
  5. 17 Dec, 2020 1 commit
  6. 12 Dec, 2020 3 commits
  7. 09 Dec, 2020 3 commits
  8. 25 Nov, 2020 1 commit
  9. 26 Oct, 2020 1 commit
    • Claudio Saavedra's avatar
      gmain: g_main_context_check() can skip updating polled FD sources · fa45688f
      Claudio Saavedra authored
      If there is a file descriptor source that has a lower priority
      than the one for sources that are going to be dispatched,
      all subsequent file descriptor sources (internally sorted by
      file descriptor identifier) do not get an update in their GPollRec
      and later on wrong sources can be dispatched.
      
      Fix this by first finding the first GPollRec that matches the current
      GPollFD, instead of relying on it to be the current one. At
      the same time, document the assumptions about the ordering of the
      file descriptor records and array and make explicit in the documentation
      that the array needs to be passed to g_main_context_check() as it was
      received from g_main_context_query().
      
      Added a new test that reproduces the bug by creating two file
      descriptor sources and an idle one. Since the first
      file descriptor created has a lower identifier and a low priority,
      the second one is not dispatched even when it has the same, higher,
      priority as the idle source. Af...
      fa45688f
  10. 23 Oct, 2020 1 commit
  11. 19 Oct, 2020 1 commit
  12. 16 Oct, 2020 3 commits
    • LRN's avatar
      Fix the 6-days-until-the-end-of-the-month bug · 807e4fdc
      LRN authored
      The addition causes the date to shift
      forward into 1st of the next month, because a 0-based offset
      is compared to be "more than" the days in the month instead of "more than
      or equal to".
      
      This is triggered by corner-cases where transition date is 6 days
      off the end of the month and our calculations put it at N+1th day of the
      month (where N is the number of days in the month). The subtraction should
      be triggered to move the date back a week, putting it 6 days off the end;
      for example, October 25 for CET DST transition; but due to incorrect comparison
      the date isn't shifted back, we add 31 days to October 1st and end up
      at November 1st).
      
      Fixes issue #2215.
      807e4fdc
    • LRN's avatar
      Add a test for the 6-days-until-EOM bug · 3a0e7744
      LRN authored
      3a0e7744
    • Philip Withnall's avatar
      gslice: Inline win32 implementation of g_getenv() to avoid deadlock · 7f450baa
      Philip Withnall authored
      
      
      The win32 implementation of `g_getenv()` uses GSlice (from within
      GQuark), which results in a deadlock when examining the `G_SLICE`
      environment variable.
      
      Fix that by inlining a basic implementation of `g_getenv()` at that call
      site.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <pwithnall@endlessos.org>
      
      Fixes: #2225
      7f450baa
  13. 15 Oct, 2020 5 commits
    • Philip Withnall's avatar
      tests: Add a basic test for GTimeZone caching · 976f48b4
      Philip Withnall authored
      
      
      This tests the previous few commits.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <pwithnall@endlessos.org>
      976f48b4
    • António Fernandes's avatar
      Revert "gtimezone: Cache timezones based on the identifier they were created by" · cfe593a3
      António Fernandes authored
      This reverts commit 851241f1.
      
      That commit avoids a performance regression but introduces a behavior regression:
      changes to /etc/localtime have no effect for the remaining of the application's
      runtime.
      
      With the optimization introduced by the previous commit, we can pass NULL to
      g_time_zone_new() repeatedly with no performance drawback, so we no longer have
      to workaround this case.
      
      Fixes: #2224
      cfe593a3
    • António Fernandes's avatar
      gtimezone: Cache default timezone indefinitely · 3ab278da
      António Fernandes authored
      We cache GTimeZone instances to avoid expensive construction when the
      same id is requested again.
      
      However, if the NULL id is passed to g_time_zone_new(), we always
      construct a new instance for the default/fallback timezone.
      
      With the recent introduction of some heavy calculations[1], repeated
      instance construction in such cases has visible performance impact in
      nautilus list view and other such GtkTreeView consumers.
      
      To avoid this, cache reference to a constructed default timezone and
      use it the next time g_time_zone_new() is called with NULL argument,
      as long as the default identifier doesn't change. We already did the
      same for the local timezone[2].
      
      Fixes: #2204
      
      Based on idea proposed by Sebastian Keller <skeller@gnome.org>.
      
      [1] 25d950b6
      [2] 551e8366
      3ab278da
    • António Fernandes's avatar
      gtimezone: Set resolved_identifier earlier · 19c5e13f
      António Fernandes authored
      We have been passing a &resolved_identifier address around for multiple
      functions to set it. Each function may either:
      
          1.  leaving it for the next function to set, if returning early;
          2.  set it to a duplicate of the passed identifier, if not NULL;
          3.  get a fallback value and set it, otherwise.
      
      This can be simplified by setting it early to either:
      
          1.  a duplicate of the passed identifier, if not NULL;
          2.  a fallback value, otherwise.
      
      This way we can avoid some unnecessary string duplication and freeing.
      Also, on Windows, we avoid calling windows_default_tzname() twice.
      
      But the main motivation for this change is enabling the performance
      optimization in the next commit.
      19c5e13f
    • António Fernandes's avatar
      gtimezone: Split out fallback timezone identification for unix · 7124b91e
      António Fernandes authored
      When the TZ environment variable is not set, we get the local timezone
      identifier by reading specific files.
      
      We are going to need these identifiers earlier, so split this logic into
      its own function, in preparation for the next commit.
      
      Based on idea proposed by Sebastian Keller <skeller@gnome.org>.
      7124b91e
  14. 14 Oct, 2020 1 commit
    • Benjamin Berg's avatar
      gmain: Fix possible locking issue in source unref · 6077ec3e
      Benjamin Berg authored
      When unref'ing child sources, the lock is already held. But instead of
      passing TRUE to g_source_unref_internal it currently passes whether the
      lock was already held outside of the current invocation. Just pass TRUE
      to fix this possible issue.
      6077ec3e
  15. 13 Oct, 2020 1 commit
  16. 05 Oct, 2020 3 commits
  17. 01 Oct, 2020 2 commits
  18. 30 Sep, 2020 5 commits