1. 04 Feb, 2021 5 commits
    • Philip Withnall's avatar
      gwinhttpfile: Avoid arithmetic overflow when calculating a size · 0cbad673
      Philip Withnall authored
      
      
      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's avatarPhilip Withnall <pwithnall@endlessos.org>
      Helps: #2319
      0cbad673
    • 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
      gobject: Use g_memdup2() instead of g_memdup() in obvious places · 6110caea
      Philip Withnall authored
      
      
      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's avatarPhilip Withnall <pwithnall@endlessos.org>
      Helps: #2319
      6110caea
    • Philip Withnall's avatar
      gio: Use g_memdup2() instead of g_memdup() in obvious places · be883434
      Philip Withnall authored
      
      
      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's avatarPhilip Withnall <pwithnall@endlessos.org>
      Helps: #2319
      be883434
    • 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. 03 Feb, 2021 5 commits
  3. 02 Feb, 2021 1 commit
  4. 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
  5. 11 Jan, 2021 3 commits
  6. 08 Jan, 2021 1 commit
  7. 07 Jan, 2021 5 commits
  8. 04 Jan, 2021 3 commits
  9. 30 Dec, 2020 1 commit
  10. 21 Dec, 2020 3 commits
  11. 17 Dec, 2020 3 commits
  12. 13 Dec, 2020 1 commit
  13. 12 Dec, 2020 3 commits
  14. 11 Dec, 2020 2 commits